Полное руководство по useEffect

+1

Работа с формами в React.js, используя базовый инструментарий

Мне кажется метод validate работает не так как ожидается. Указание второго параметра в setState это callback который будет вызыван асинхронно в тот момент когда стейт изменится. В этот callback можно написать какyю-то дополнительную логику но возвращаемое значение будет проигнарировано. Поэтому в строке () => false нет смысла. Но почему же тогда все работает?! Похоже что в случае, когда строка пустая метод возвращает undefined, который в логическом выражении неявно приводится к false. Мне кажется следут явно написать return false, это сделает код более понятным.

Внедрение зависимостей в Go

У меня сложилось впечатление, что все пытаются критиковать данный подход из-за, якобы, переусложнения и неявности. Но почему-то все забывают что, во-первых, это игрушечный пример, в котором затраты на создание и обслуживание контейнера только начинают быть сопоставимы и пользой от него. В реальных приложениях у вас будут десятки классов и структур и если не использовать DI, main превратится к огромных кусок нечитаемого и неподдерживаемого кода. Данный пример призван просто продемонстрировать концепцию, если бы он был сложнее, тем, кто впервые сталкнулся с понятием DI, было бы неимоверно сложно понять в чем же его суть. Во-вторых, я в корне не согласен с тем, что DI, распространен только в Java. Приведу, возможно, неожиданные примеры из фронтенда: DI — основная архитектурная идея Angular, с другой стороны React Context — своего рода DI для распространения данных и функционала между компонентами (а возможно и других компонентов). В-третьих, неужели ни у кого из комментаторов не возникало потребности иметь в системе две имплементации схожего функционала? И дело может быть не в таких фундаментальных сущностях как база данных, а, например, в алгоритме расчета налога в зависимости от страны или других персонализированных алгоритмах. DI — это зрелая и сложившаяся концепция которая показывает свою практическую полезность на протяжении уже долго времени. Довольно странно слышать, что это оверинженириг или глупое усложнение. Это техника, которая может показаться избыточной на «короткой дистанции», но если у вас действительно сложный коммерческий продукт, без DI вы просто в определенный момент начнете строить диаграммы зависимостей на бумажке, в то время как DI дает возможность абстрагироваться от полной картины зависимостей и переложить рутинную работу на подходящий для этого инструмент.