Да, но это слишком синтетический пример, тут действительно стоит подумать и пообщаться с этим человеком. Это уж точно не "сначала работал 7 месяцев в одном месте, а потом 3 месяца в другом — я закрываю файл". В данном случае вообще абсурд - 3 месяца могло на самом деле быть 2-мя с половиной с увольнением во время испытательного срока (собственно, он делается не только для РАБотодателя)
Когда человек увольняется, у него есть причины на это. А их может быть множество:
Низкая ЗП для своего уровня и не получение желаемого повышения
Надоел проект
Ожидания и реальность не совпали. Для этого и создан испытательный срок - не только для работодателя.
Тут не два варианта. Жизнь - это не монета с орлом и решкой, а немного более сложная штука. Но из-за эвристики доступности мы не можем этого сразу осознать - ведь наш несовершенный мозг, любящий все упрощать, выдает нам решение, которое далеко не всегда является истинной и нуждается в дополнительной проверке.
прыгает с места на место ради увеличения зарплаты (но это значит, что он не особо хорош, так как хороших специалистов удерживают зарплатой, если он собирается уходить на большую)
А вы не думали, что просто не хотят повышать, например? Если человек смог уйти в другую компанию на более высокую ЗП, значит, может быть, он не такой уж и плохой специалист, раз смог ее получить, пускай и в другой компании? Это не говоря уже о дргих причинах, которые могут быть.
или он просто бестолковый или тяжелый человек которого «сокращают»
Такие люди вряд ли надолго задержаться в одной неинтересной области. Опять же, проверяется на собеседовании.
И это всего лишь несколько примеров. Каждый случай индивидуален. И чтобы делать выводы, надо иметь статистику и не заниматься ерундой.
Т.е. к чему я веду в конкретном примере: если не знаете куда развиваться — можно посмотреть стоимости соответствующих навыков и исходить уже не только из личных предпочтений, но и из конъюнктуры
Я практически уверен, что если выбор идёт из личных предпочтений (а именно - делать то, что нравится), то вероятность заработать будет больше в долгосрочной, нежели если идти по "конъюктуре"
Помню, как они мне оперативку по гарантии "возвращали". Цитата: "Мы проблему выявили, но производитель не выявил. Иди разбирайся сам". 25K минус на ровном месте
Типа, мы нажимаем на редактирование и редактируем текст? Но тут у нас в любом случае будет какой-то Input с кнопкой сохранения, например и мы не должны менять стейт на каждый ввод символа, тут он и не нужен) А после сохранения из рефа тянем. Не очень понимаю, зачем вручную мутировать массив и потом вызывать перерендер в данном случае.
Это классно, конечно, но не будет ли преждевременной оптимизацией? И почему должен быть пере-рендер, если мы передаём key для каждого элемента списка, например. Или я неправильно контекст задачи понял?
Проблема вашей краткости в том, что это очень удобно - сказать, что все плохо, но что именно плохо - не сказать. Это говорит либо о том, что вы не можете сказать ничего конкретного, либо то, что вы даже не попытались потратить хоть какое-то время, чтобы немного вникнуть.
Что здесь для вас не очевидно? У формы 2 блока, каждый блок описан отдельным компонентом. Лишние рендеры отсутствуют, т. к. в библиотеке позаботились о том, как правильно хранить состояние формы.
Я бы очень хотел посмотреть, как эта форма будет выглядеть на MobX в вашем видении. Возможно вы действительно понимаете, как можно сделать красивее, был бы рад увидеть это, а не только услышать критику без аргументов.
подход слишком "реактовский" и это огромнейший минус, т.к. реакт годится только на рендера HTML'a, но ни как не на управление состоянием.
Это слишком сильное заявление. Может быть подход не годится именно для вас? Какие конкретно проблемы моего решение перед решением на MobX? То, что прокси не используется? Надо на практике сравнивать производительность. То, что выглядит неочевидно? Сделайте лучше на MobX!
Форма небольшая, но я постарался вместить туда основные моменты - валидацию, разделение на отдельные блоки, скрытие полей, форма в форме, массив полей и кастомные поля с валидацией.
В качестве библиотеки форм взял react-hook-form. По итогу:
Никаких onChange/value, достаточно добавить только name для поля, но для этого надо заранее подготовить контролы.
Нет лишних перерендеров. Я подробно не изучал, но как понимаю, там внутри механизм publish/subscribe работает.
Легко перемещать блоки - достаточно просто перенести блок в разметке.
И этой логики обычно в рамках одного комонента на примере формы гораздо больше, с описанием валидациий и тд и тп. Описывать всё это используя хуки, это адская лапша и говнокод.
Предлагаю сделать вам эту форму на MobX. Миф, что на хуках обязательно будет лапша, я постарался разрушить. Подход масштабируется, так что размер формы не важен. Хотя я вполне допускаю, что могут быть какие-то подводные камни - Они всегда могут быть где-либо.
Я, кстати, не забыл, скоро вы сможете посмотреть на мой "говнокод" формы с хуками. Я не делаю супер-сложную форму, стараюсь вместить нюансы в маленькую (скрытие полей/блоков, валидацию, изменяемый список (массив) полей), форму в форме, кастомные контролы.
В целом я не считаю, что хуки победят по чистоте кода - думаю, можно и там, и там хорошо написать. Посмотрите на альтернативный подход, может, предложите свои идеи для улучшения/усложнения для задачи Также для себя, может, что-то найдете и не будете так категорично относится к управлению состоянием на хуках.
Изначально речь шла не только о вашей области, а в целом о роли ВУЗа в обучении. Вы только в одном месте упомянули про вашу область, в остальном же я вижу обобщение на разработку в целом.
Начнем с того, что специалист становится специалистом как раз потому, что решает задачи, которые до этого никогда ее решал. И спустя тысячи часов обучения на своих ошибках он становится специалистом в какой-то области и в ней способен решать в том числе и те задачи, которые он не решал, в голове уже построены нужные абстракции. За это время он успеет много чего прочитать/отпрактиковать/опробовать. Ему вряд ли встретиться что-то абсолютно новое, так как он уже в этом сидит, он так или иначе будет иметь точки соприкосновения. Конечно, если не давать задачю по ML бекендеру. Такой ерундой уж точно заниматься не следует.
Вывод следующий - за тысячи часов практики специалист получит необходимую базу и будет решать задачи. 5 лет ВУЗа ему скорее всего что-то дадут, если там будут предметы, покрывающие его специальность, но это лишь позволит ему быстрее развиваться как специалист, но никак не ограничит его в дальнейшем.
Я обратил внимание, что вы занимались 3D-движками. Ну, значит ваша база транспонирование матриц. И многое-многое другое, что вы получили за все время обучения и практики. Ваша обишка только в том, что вы пытаетесь всем эту базу навязать, которая вовсе не обязательна в других сферах разработки. Это ваша база, как разработчика игр. И я очень сомневаюсь, что эти знания нужны frontend- или backend-разработчикам, например.
Вы бы гарантированно получили несоответствие вида реальный сеньор = джун в МКБ; реальный джун = сеньор в МКБ. Удачи с таким подходом)
Есть ещё такая вещь, как Zobrist-хеширование
И опять люди задают вопросы на русском, на котором эта нейросеть работает хуже..
Да, но это слишком синтетический пример, тут действительно стоит подумать и пообщаться с этим человеком. Это уж точно не "сначала работал 7 месяцев в одном месте, а потом 3 месяца в другом — я закрываю файл". В данном случае вообще абсурд - 3 месяца могло на самом деле быть 2-мя с половиной с увольнением во время испытательного срока (собственно, он делается не только для РАБотодателя)
Это называется "генерализация частного случая". Вы делаете вывод по одному примеру. И это большая ошибка.
Когда человек увольняется, у него есть причины на это. А их может быть множество:
Низкая ЗП для своего уровня и не получение желаемого повышения
Надоел проект
Ожидания и реальность не совпали. Для этого и создан испытательный срок - не только для работодателя.
Тут не два варианта. Жизнь - это не монета с орлом и решкой, а немного более сложная штука. Но из-за эвристики доступности мы не можем этого сразу осознать - ведь наш несовершенный мозг, любящий все упрощать, выдает нам решение, которое далеко не всегда является истинной и нуждается в дополнительной проверке.
А вы не думали, что просто не хотят повышать, например? Если человек смог уйти в другую компанию на более высокую ЗП, значит, может быть, он не такой уж и плохой специалист, раз смог ее получить, пускай и в другой компании? Это не говоря уже о дргих причинах, которые могут быть.
Такие люди вряд ли надолго задержаться в одной неинтересной области. Опять же, проверяется на собеседовании.
И это всего лишь несколько примеров. Каждый случай индивидуален. И чтобы делать выводы, надо иметь статистику и не заниматься ерундой.
Здесь соглашусь - вместо езды по асфальту выбирают грунтовку и предлагают положить щебень, чтобы лучше ехалось
Я практически уверен, что если выбор идёт из личных предпочтений (а именно - делать то, что нравится), то вероятность заработать будет больше в долгосрочной, нежели если идти по "конъюктуре"
Помню, как они мне оперативку по гарантии "возвращали". Цитата: "Мы проблему выявили, но производитель не выявил. Иди разбирайся сам". 25K минус на ровном месте
@markelov69 Ждем ответ по существу :)
Понял теперь)
Типа, мы нажимаем на редактирование и редактируем текст? Но тут у нас в любом случае будет какой-то Input с кнопкой сохранения, например и мы не должны менять стейт на каждый ввод символа, тут он и не нужен) А после сохранения из рефа тянем. Не очень понимаю, зачем вручную мутировать массив и потом вызывать перерендер в данном случае.
Это классно, конечно, но не будет ли преждевременной оптимизацией? И почему должен быть пере-рендер, если мы передаём key для каждого элемента списка, например. Или я неправильно контекст задачи понял?
Чем:
очевиднее, чем это?
Проблема вашей краткости в том, что это очень удобно - сказать, что все плохо, но что именно плохо - не сказать. Это говорит либо о том, что вы не можете сказать ничего конкретного, либо то, что вы даже не попытались потратить хоть какое-то время, чтобы немного вникнуть.
Что здесь для вас не очевидно? У формы 2 блока, каждый блок описан отдельным компонентом. Лишние рендеры отсутствуют, т. к. в библиотеке позаботились о том, как правильно хранить состояние формы.
Я бы очень хотел посмотреть, как эта форма будет выглядеть на MobX в вашем видении. Возможно вы действительно понимаете, как можно сделать красивее, был бы рад увидеть это, а не только услышать критику без аргументов.
Это слишком сильное заявление. Может быть подход не годится именно для вас? Какие конкретно проблемы моего решение перед решением на MobX? То, что прокси не используется? Надо на практике сравнивать производительность. То, что выглядит неочевидно? Сделайте лучше на MobX!
@markelov69 Все готово)
https://habr.com/ru/post/660573/comments/#comment_24728448
Готово)
Форма небольшая, но я постарался вместить туда основные моменты - валидацию, разделение на отдельные блоки, скрытие полей, форма в форме, массив полей и кастомные поля с валидацией.
В качестве библиотеки форм взял react-hook-form.
По итогу:
Никаких onChange/value, достаточно добавить только name для поля, но для этого надо заранее подготовить контролы.
Нет лишних перерендеров. Я подробно не изучал, но как понимаю, там внутри механизм publish/subscribe работает.
Легко перемещать блоки - достаточно просто перенести блок в разметке.
Демо: CodeSandbox
Предлагаю сделать вам эту форму на MobX. Миф, что на хуках обязательно будет лапша, я постарался разрушить. Подход масштабируется, так что размер формы не важен. Хотя я вполне допускаю, что могут быть какие-то подводные камни - Они всегда могут быть где-либо.
Надо всегда рассматривать вопрос индивидуально. У вас, нерепрезентативна выборка.
Я, кстати, не забыл, скоро вы сможете посмотреть на мой "говнокод" формы с хуками. Я не делаю супер-сложную форму, стараюсь вместить нюансы в маленькую (скрытие полей/блоков, валидацию, изменяемый список (массив) полей), форму в форме, кастомные контролы.
В целом я не считаю, что хуки победят по чистоте кода - думаю, можно и там, и там хорошо написать. Посмотрите на альтернативный подход, может, предложите свои идеи для улучшения/усложнения для задачи
Также для себя, может, что-то найдете и не будете так категорично относится к управлению состоянием на хуках.
Изначально речь шла не только о вашей области, а в целом о роли ВУЗа в обучении. Вы только в одном месте упомянули про вашу область, в остальном же я вижу обобщение на разработку в целом.
Начнем с того, что специалист становится специалистом как раз потому, что решает задачи, которые до этого никогда ее решал. И спустя тысячи часов обучения на своих ошибках он становится специалистом в какой-то области и в ней способен решать в том числе и те задачи, которые он не решал, в голове уже построены нужные абстракции. За это время он успеет много чего прочитать/отпрактиковать/опробовать. Ему вряд ли встретиться что-то абсолютно новое, так как он уже в этом сидит, он так или иначе будет иметь точки соприкосновения. Конечно, если не давать задачю по ML бекендеру. Такой ерундой уж точно заниматься не следует.
Вывод следующий - за тысячи часов практики специалист получит необходимую базу и будет решать задачи. 5 лет ВУЗа ему скорее всего что-то дадут, если там будут предметы, покрывающие его специальность, но это лишь позволит ему быстрее развиваться как специалист, но никак не ограничит его в дальнейшем.
Я обратил внимание, что вы занимались 3D-движками. Ну, значит ваша база транспонирование матриц. И многое-многое другое, что вы получили за все время обучения и практики. Ваша обишка только в том, что вы пытаетесь всем эту базу навязать, которая вовсе не обязательна в других сферах разработки. Это ваша база, как разработчика игр. И я очень сомневаюсь, что эти знания нужны frontend- или backend-разработчикам, например.