Comments 5
Теперь бы писать в статьях что-то более интересное, чем пересказы туториалов.
Если речь идёт о переиспользуемом коде, то надо писать про архитектуру, обеспечивающую хорошую переиспользуемость. А не «реакт может А, Б, В». Это все могут.
1) Как корректно разруливать ситуации «нам нужен блок компонент в пяти разных местах, но в каждом немного по-разному» без сваливания в props hell;
2) Как идиоматично создавать компоненты из модели и собирать изменения обратно в модель. Как при этом избегать бессмысленных и беспощадных перерисовок DOM (это как раз самая что ни на есть практика переиспользуемых компонент);
3) Как избавиться от идиотской практики реакта объявлять «модельные» компоненты. Потому что это не компоненты, они не имеют никакого отношения к UI, и нет ни одной причины делать их extends React.Component кроме неуёмного желания писать код максимально квадратно-гнездовым способом, даже в ущерб смыслу.
Вот это были бы хорошие моменты для освещения.
Если речь идёт о переиспользуемом коде, то надо писать про архитектуру, обеспечивающую хорошую переиспользуемость. А не «реакт может А, Б, В». Это все могут.
1) Как корректно разруливать ситуации «нам нужен блок компонент в пяти разных местах, но в каждом немного по-разному» без сваливания в props hell;
2) Как идиоматично создавать компоненты из модели и собирать изменения обратно в модель. Как при этом избегать бессмысленных и беспощадных перерисовок DOM (это как раз самая что ни на есть практика переиспользуемых компонент);
3) Как избавиться от идиотской практики реакта объявлять «модельные» компоненты. Потому что это не компоненты, они не имеют никакого отношения к UI, и нет ни одной причины делать их extends React.Component кроме неуёмного желания писать код максимально квадратно-гнездовым способом, даже в ущерб смыслу.
Вот это были бы хорошие моменты для освещения.
Это конечно ИМХО, но я бы еще убрал нахрен громоздкие классы и заменил их функциональными компонентами, а оперирование состоянием перевёл на хуки.
Можно сделать ещё гораздо круче и оперирование состоянием заменить на MobX, и использовать его как для локальных стейтов компонентов, так и для глобальных стейтов.
MobX, и использовать его как для локальных стейтов компонентов, так и для глобальных стейтов
Считаю что для локальных стейтов всё же лучше использовать «нативный» реактовский стейт. Чтобы компонент был самодостаточным, и не зависил от стейт-менеджера, и в идеале можно было тягать его между разными проектами.
А всё что глобальное / уровень приложения / бизнесс-логики — вот это всё рулить уже mobx-ом.
С 2016 года использую только MobX в паре с реактом и никакого Redux, он для меня остался в далеком прошлом, кошмарном, тормознутом и с гигантской лапшой бесполезного и однообразного кода) Вообще странно что до сих пор его используют. А сам по себе голый реакт считаю достаточно ущербным без MobX'a. MobX превращает его в крутой реактивный и полноценный инструмент, и не надо думать о производительности, всё уже оптимизировано из коробки.
Sign up to leave a comment.
Не пиши одно и то же: как переиспользуемые компоненты React помогут фронтенд-разработчику быстрее создавать приложения