Comments 5
Получается можно забыть про классовые компоненты?
Да, в реальном коде почти нет ситуаций когда классовый компонент будет лучше функционального, можно вспомнить про error boundary, который для своей реализации требует метод из классового компонента, но в противовес есть сторонние библиотеки, реализующие нужное поведение под капотом, или можно зайти на официальный сайт React и скопировать классовый компонет error boundary, и немного его поправить под себя, какой то специфичной логики там нет.
Не стал бы так однозначно голосовать за хуки и хоронить statefull компоненты. Архитектурно, хуки - это костыли, нивелирующие недостатки функциональных компонентов. Хуки, реализованы коллбеками, от которых давно стали отказываться в пользу промисов. Ошибки связанные с хуками сложно дебажить, а так же они могут вызывать утечки памяти.
Ну может это и костыли, но разработчики React сказали что классы фу-фу-фу, и надо использовать хуки, в теории оба подхода имеют свои плюсы, но джуну не нужно знать о плюсах подхода который больше мертв чем жив. Про дебаг ошибок сказать ничего не могу, сам на классах писал довольно мало и переходя на хуки мне становилось проще писать код и искать в нем ошибки
Основные плюсы React это: Virtual DOM... Такой подход работает быстрее, потому как не включает в себя все тяжеловесные части реального DOM
Я бы не записывал в плюсы, это просто реализация поиска изменений для оптимизации вызова DOM API. Например, в Angular его нет и там реактивные алгоритмы справляются в некоторых кейсах даже быстрее.
Классовые компоненты медленнее, из-за большого количества встроенных методов
Это самое большое заблуждение, классовые компоненты не могут быть медленнее функциональных априори, кроме одного случая, о нём в конце. Функциональный компонент по сути является render функцией, которая будет выполнятся на каждом рендере, а значит и всё внутри будет заново аллоцироваться. Для избежания этого мы используем хуки - useState, useMemo, useCallback, а точнее для кэширования значений. Какие подводные камни на примере useCallback. Появляется оверхед в виде массива, который используется для кэширования функций - индекс (порядок вызова хука, из-за чего и нельзя загонять под условные операторы), сама функция, массив зависимостей. На каждом рендере появляется оверхед для сравнения массивов зависимостей, а самое главное, сама функция в любом случае аллоцируется, а значит занимает память и деаллоцируется с помощью GC (хоть и в первом поколении). В классовом компоненте вместо того, чтобы создавать стрелочные функции в render методе, мы можем сделать их методами класса, а значит у нас пропадает надобность их пересоздавать, так как мы имеем доступ к актуальному полю state, и соответственно у нас пропадает надобность их кэшировать, так как они не пересоздаются. В принципе любой бенчмарк покажет вам, что классовые компоненты более производительны, чем функциональные компоненты. Единственное исключение - если в функциональном компоненте не используются хуки.
Неплохо было бы, если бы "правильные" ответы на вопросы для джунов не содержали ошибок. Например про реакт фрагмент 2 формы записи на то и 2, что имеют различия (в сокращённой записи нельзя прописать key)
Бедные нынешние джуны... Пока не поработаешь в реальном проекте несколько месяцев, реально это все не осознаешь, только если зубрить.
Бедные нынешние джуны... Пока не поработаешь в реальном проекте несколько месяцев, реально это все не осознаешь, только если зубрить.
Вопросы к собеседованию React (Junior level)