Pull to refresh
1
0
Олег Иванов@oliivanov

User

Send message

Поясните что вы имеете ввиду

Я про это. Возможно, это просто утрированный пример и можно сделать элегантнее. Я на mobx писал давно и недолго, в формате "написал и забыл", так что докапываться к нему сильно не буду)

То, что mobx позволяет так делать - это плюс, конечно, это выглядит красиво и удобно. В принципе, интересно будет потыкать в будущем при возможности.

Тут то ли стокгольмский синдром, то ли синдром утёнка.

Оба два, наверное)

Я надеюсь это сарказм такой? Что ни приложение на Реакте, то тормозной глюкодром. 

Это, наверное, стадия принятия) Но насчёт "тормозного глюкодрома" - как по мне, преувеличение и оценочное суждение. Есть категория людей, у которых вообще любой JavaScript - "тормозной глюкодром". А мне, например, на большинстве сайтов, норм. Всё относительно.

React позволяет быстро вкатиться и быстро разработать. И почти всегда "быстро" - антоним слова "хорошо".

В комментариях появились и уважаемый господин Карловский, и сторонники mobx. Значит, статья удалась, я счастлив)

По $mol_wire - я увидел какое-то огромное количество бойлерплейта и несколько странных решений типа превращения асинхронной функции в синхронную, а также дебаунс с помощью sleep (если этот sleep - задержка на некоторое время, как обычно, то это ж не дебаунс по идее, не?). Ну и в целом в готовый код на реакте это впилить будет сложно, тут на вид потребуется большая переделка всего и вся.

По Mobx - я пользовался им года 3 назад. После redux это, конечно, был глоток свежего воздуха, писать было гораздо проще и приятнее. Но вот глядя на пример приведённый - ну как-то многовато кода писать приходится, не находите? Каждый компонент со стейтом в observer запихивать, хуки использовать и тот же useEffect... А ещё у mobx огромный бандл в 60 Кб. А у Zustand, например, 1.2 Кб. И у Zustand простое и лаконичное API, которого в целом хватает. Может он и умеет не всё, что умеет mobx, но хватает ведь.

Флеймогонная тема, в общем)

Реренедеры могут быть болью, когда из-за них сильно проседает производительность или сбрасывается стейт. У меня таких случаев было не очень много, поэтому я в статью и не включил.

Хотя соглашусь, что сам факт довольно бесячий. И это по сути следствие использования функциональных компонентов и обходящего их недостатки дизайна хуков (тоже как минимум спорного). Я вообще когда впервые хуки увидел, подумал что это шутка какая-то, помнится, даже сказал тимлиду фразу "Хуки это костыль". Но костыль или нет, к нему привыкаешь. Да и самое ценное, что хуки позволяют вынести логику и переиспользовать её. Как инструмент для этого они хороши, как замена стейт-менеджеру... Ну спорно. Но надо понимать, что немало современных стейт-менеджеров без хуков бы и не появились или были бы куда менее удобны.

Ну как в таких случаях говорят - Just for fun, мне кажется. Написать альтернативу React - прекрасный челлендж, который позволяет в том числе и в том самом реакте разобраться.

В целом-то, альтернатив React формата "поменьше и покороче" вагон и маленькая тележка: Preact, Solid, вот Fusor тот же. Штуки интересные, но React предсказуемое и уже всем известное решение, с кучей библиотек на все случаи жизни. А альтернативы - сегодня они есть, завтра нет, ui-китов под них обычно не завезли, ну и всё прочее.

Если в реальной жизни перескакивать с React, то скорее на Vue. Мой опыт с ним был не очень большим - 1 среднего размера проект, но мне очень понравилось, в какой-то степени это был глоток свежего воздуха.

Причины вообще 2:

  1. Потому что могу и интересно поизгаляться

  2. Чтобы невозможно было подменить эту переменную извне. Если покажете, как внутри замыкания изменить переменную, буду очень заинтересован)

Information

Rating
Does not participate
Registered
Activity

Specialization

Фронтенд разработчик
Старший
Git
Linux
ООП
Docker
CI/CD
JavaScript
TypeScript
CSS
HTML
React