Типа, мы нажимаем на редактирование и редактируем текст? Но тут у нас в любом случае будет какой-то Input с кнопкой сохранения, например и мы не должны менять стейт на каждый ввод символа, тут он и не нужен) А после сохранения из рефа тянем. Не очень понимаю, зачем вручную мутировать массив и потом вызывать перерендер в данном случае.
Это классно, конечно, но не будет ли преждевременной оптимизацией? И почему должен быть пере-рендер, если мы передаём key для каждого элемента списка, например. Или я неправильно контекст задачи понял?
Проблема вашей краткости в том, что это очень удобно - сказать, что все плохо, но что именно плохо - не сказать. Это говорит либо о том, что вы не можете сказать ничего конкретного, либо то, что вы даже не попытались потратить хоть какое-то время, чтобы немного вникнуть.
Что здесь для вас не очевидно? У формы 2 блока, каждый блок описан отдельным компонентом. Лишние рендеры отсутствуют, т. к. в библиотеке позаботились о том, как правильно хранить состояние формы.
Я бы очень хотел посмотреть, как эта форма будет выглядеть на MobX в вашем видении. Возможно вы действительно понимаете, как можно сделать красивее, был бы рад увидеть это, а не только услышать критику без аргументов.
подход слишком "реактовский" и это огромнейший минус, т.к. реакт годится только на рендера HTML'a, но ни как не на управление состоянием.
Это слишком сильное заявление. Может быть подход не годится именно для вас? Какие конкретно проблемы моего решение перед решением на MobX? То, что прокси не используется? Надо на практике сравнивать производительность. То, что выглядит неочевидно? Сделайте лучше на MobX!
Форма небольшая, но я постарался вместить туда основные моменты - валидацию, разделение на отдельные блоки, скрытие полей, форма в форме, массив полей и кастомные поля с валидацией.
В качестве библиотеки форм взял react-hook-form. По итогу:
Никаких onChange/value, достаточно добавить только name для поля, но для этого надо заранее подготовить контролы.
Нет лишних перерендеров. Я подробно не изучал, но как понимаю, там внутри механизм publish/subscribe работает.
Легко перемещать блоки - достаточно просто перенести блок в разметке.
И этой логики обычно в рамках одного комонента на примере формы гораздо больше, с описанием валидациий и тд и тп. Описывать всё это используя хуки, это адская лапша и говнокод.
Предлагаю сделать вам эту форму на MobX. Миф, что на хуках обязательно будет лапша, я постарался разрушить. Подход масштабируется, так что размер формы не важен. Хотя я вполне допускаю, что могут быть какие-то подводные камни - Они всегда могут быть где-либо.
Я, кстати, не забыл, скоро вы сможете посмотреть на мой "говнокод" формы с хуками. Я не делаю супер-сложную форму, стараюсь вместить нюансы в маленькую (скрытие полей/блоков, валидацию, изменяемый список (массив) полей), форму в форме, кастомные контролы.
В целом я не считаю, что хуки победят по чистоте кода - думаю, можно и там, и там хорошо написать. Посмотрите на альтернативный подход, может, предложите свои идеи для улучшения/усложнения для задачи Также для себя, может, что-то найдете и не будете так категорично относится к управлению состоянием на хуках.
Изначально речь шла не только о вашей области, а в целом о роли ВУЗа в обучении. Вы только в одном месте упомянули про вашу область, в остальном же я вижу обобщение на разработку в целом.
Начнем с того, что специалист становится специалистом как раз потому, что решает задачи, которые до этого никогда ее решал. И спустя тысячи часов обучения на своих ошибках он становится специалистом в какой-то области и в ней способен решать в том числе и те задачи, которые он не решал, в голове уже построены нужные абстракции. За это время он успеет много чего прочитать/отпрактиковать/опробовать. Ему вряд ли встретиться что-то абсолютно новое, так как он уже в этом сидит, он так или иначе будет иметь точки соприкосновения. Конечно, если не давать задачю по ML бекендеру. Такой ерундой уж точно заниматься не следует.
Вывод следующий - за тысячи часов практики специалист получит необходимую базу и будет решать задачи. 5 лет ВУЗа ему скорее всего что-то дадут, если там будут предметы, покрывающие его специальность, но это лишь позволит ему быстрее развиваться как специалист, но никак не ограничит его в дальнейшем.
Я обратил внимание, что вы занимались 3D-движками. Ну, значит ваша база транспонирование матриц. И многое-многое другое, что вы получили за все время обучения и практики. Ваша обишка только в том, что вы пытаетесь всем эту базу навязать, которая вовсе не обязательна в других сферах разработки. Это ваша база, как разработчика игр. И я очень сомневаюсь, что эти знания нужны frontend- или backend-разработчикам, например.
"крутой" прогер, который придет на высокую зарплату и споткнется о транспорнированную матрицу не будет в команде восприниматься спецом
Это стереотип, что крутой прогер должен знать, как транспонировать матрицу - вовсе нет! Он может быть прекрасный программистом и, например, не разбираться в матрицах, безграмотно писать и т. д., так как не пользуется этим ввиду того, что нет такой необходимости. А если он делает движок для игр, то он с этим будет сталкиваться и получит именно те навыки, которые ему нужны. Это будут как раз систематезированные навыки (которые получены путем практики). Только практика позволяет выработать нужные нейронные связи, на это нужно время, в ВУЗе такого не будет. Ну научишься ты решать типовые задачки на матрицы, только толку от этого немного, если тебе это не интересно и ты не идешь в GameDev/ML. Программист крут не потому, что он умеет применять ВУЗовскую программу, а потому, что успешно решает задачи, которые требуются и пишет достаточно хороший код для того, чтобы его поддерживать (либо недостаточно - опять же, все зависит от задач, требований и много чего еще). И если меня в команде не будут воспринимать спецом из-за незнания транспонирования матрицы - то мне будет все равно, так как это уже не моя команда, а люди, которые ввиду недостаточной информации пытаются сделать выводы и попадают под действие когнитивных искажений.
чтобы время потраченное на эти 960 страниц было потрачено не зря Думаю, если время, потраченное на эту книгу, не даст пользы, то чтьающий ее даже не джун...
Это доказывает тупость статьи, а также опровергает саму себя. В общем, вывод следующий - чудес не бывает и нанять программиста если ты сам не программист - это очень нетривиальная задача. И уж тем более пытаться собеседование.
Вы не поверите, но существуют такие продукты, за которые хочется засылать деньги вне зависимости от того, какая у них политика. Вот вы не пользовались продуктами Jetbrains, поэтому вам трудно понять это. Они действительно подарили лицензии до Октября месяца. Что будет после - никто не знает.
Думаю, не проблема будет сменить аккаунт и оплачивать тем же PayWithMoon, либо иностранной картой. Выход будет. Может, криптой можно будет оплачивать, кто знает :)
На крайний случай можно использовать сервисы помощи по оплате.
Может быть и может, но в этом нет смысла - смерть произойдет рано или поздно не по естественным причинам. Закон больших чисел, ничего не поделать. А если и повезет, смерть земли/солнца/вселенной доделаю свое дело.
Типа, мы нажимаем на редактирование и редактируем текст? Но тут у нас в любом случае будет какой-то 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-разработчикам, например.
Это стереотип, что крутой прогер должен знать, как транспонировать матрицу - вовсе нет! Он может быть прекрасный программистом и, например, не разбираться в матрицах, безграмотно писать и т. д., так как не пользуется этим ввиду того, что нет такой необходимости. А если он делает движок для игр, то он с этим будет сталкиваться и получит именно те навыки, которые ему нужны. Это будут как раз систематезированные навыки (которые получены путем практики). Только практика позволяет выработать нужные нейронные связи, на это нужно время, в ВУЗе такого не будет. Ну научишься ты решать типовые задачки на матрицы, только толку от этого немного, если тебе это не интересно и ты не идешь в GameDev/ML. Программист крут не потому, что он умеет применять ВУЗовскую программу, а потому, что успешно решает задачи, которые требуются и пишет достаточно хороший код для того, чтобы его поддерживать (либо недостаточно - опять же, все зависит от задач, требований и много чего еще). И если меня в команде не будут воспринимать спецом из-за незнания транспонирования матрицы - то мне будет все равно, так как это уже не моя команда, а люди, которые ввиду недостаточной информации пытаются сделать выводы и попадают под действие когнитивных искажений.
Оно как раз отмечается в FEN-нотации)
Это доказывает тупость статьи, а также опровергает саму себя. В общем, вывод следующий - чудес не бывает и нанять программиста если ты сам не программист - это очень нетривиальная задача. И уж тем более пытаться собеседование.
Вы не поверите, но существуют такие продукты, за которые хочется засылать деньги вне зависимости от того, какая у них политика. Вот вы не пользовались продуктами Jetbrains, поэтому вам трудно понять это. Они действительно подарили лицензии до Октября месяца. Что будет после - никто не знает.
Если удобство пользования пиратской версией сопоставимо с удобством пользования лицензионной, то в текущем контексте я выберу первый вариант :)
Думаю, не проблема будет сменить аккаунт и оплачивать тем же PayWithMoon, либо иностранной картой. Выход будет. Может, криптой можно будет оплачивать, кто знает :)
На крайний случай можно использовать сервисы помощи по оплате.
Если постоянно работать с матрицами, придет понимание, что нужно дополнительно почитать. ВУЗ ускорит это понимание, не спорю, но вовсе не обязателен.
Систему и связи даёт практика, а не ВУЗ
Может быть и может, но в этом нет смысла - смерть произойдет рано или поздно не по естественным причинам. Закон больших чисел, ничего не поделать. А если и повезет, смерть земли/солнца/вселенной доделаю свое дело.
Надо просто заниматься тем, что тебе нравится и не забивать себе мозг. А там как уж будет. Ошибку выжившего никто не отменял.