По поводу мобилок хороший аргумент, по поводу кита не совсем согласен. На проекте может быть штук 7 разных шрифтов, это значит неизбежно появление small, superSmall, extraSmall и тд.
Вот у меня есть вопрос. Сможет ли typescript защитить от неконсистентных данных пришедших с сервера? Можно хоть до посинения типизировать свой код, но однажды с бэка прийдёт строка вместо массива и весь "строготипизированный код" рассыпется как карточный домик. Так и какой тогда смысл от этого полурешения?
Eslint, типы Typescript, Prettier, настройка husky, Storybook и регрессионное тестирование.
Как это говно никуда не денется? Его станет меньше. Куда меньше. Чем больше таких рамок, тем лучше бизнесу. Быстрее фичи, меньше тех. долга, меньше рефакторинга.
Ни один из этих инструментов может не спасти от говнокода от слова совсем. Говонокод — это не «забыл поставить точку с запятой», а сложный, не поддающийся никакому рефакторингу запутанный монолит. И он может проходить все тесты. И es-lint ругаться не будет. И вообще всё будет отлично ровно до того момента, как там надо поправить баг или расширить функционал.
Если вы фигачите загрузку данных и прочий бизнес в компонентах, то ваш код очень сильно пахнет, не зависимо от реакта. И callback-hell был еще задолго до того, как ФП стало набирать популярность: в nodejs, например.
Если этот бизнес будет относиться только к этому конкретному компоненту, зачем его выносить куда-то?
Ах да, и модалки которые в редаксе делаются императивно dispatch(showModal(modalName)) было очень больно делать декларативно. Есть вроде чистый компонент таблицы какой-нибудь и давай его пачкать стейтом isVisible итд.
Пока какой-то крупный проект не изъявит желание перейти на svetle и его опыт не окажется положительным, надежды на svetle как на конкурента тройки крайне малы, ИМХО.
Не переживай. По факту, за день ты сделал довольно большой кусок функционала и писать вещи в стиле «В общем, в React не получилось :(» в таких случаях позволяют себе только ЧСВ-шники 81 лвл-а (которых в front-end каждый второй). Вопрос, надо ли тебе работать в такой команде? Твой затраченный день стоит, как минимум, вежливости со стороны этих js гуру.
Накидал 2 простых примера, которые показыват на практике кейс, который я описал:
1. С редаксом, при клике вызывается экшен и страница перерендеривается, хотя на ней нечему обновляться: codesandbox.io/s/reactredux-70hm1
2. С мобиксом, при клике компонент не перерендеривается, потому что на странице нечему меняться: codesandbox.io/s/mobxreact-s7db5
В идеале конечно такого не должно происходить, я должен был убрать это свойство из mapStateToProps, но в данном случае MobX мне простит ошибку, а Redux — нет.
Если вы ещё раз внимательно почитаете, то увидите, что это не мои домыслы, а краткий перевод статьи с английского. С некоторыми моментами из этого источника я абсолютно согласен. Если вам нравится setState, используйте его на здоровье.
Во-первых, при наличии таких операций как getUser, элементы хранить надо в Map, а не в массиве.
Не монимаю, почему в данном примере надо использовать map. Я этот массив не собираюсь никак менять.
Во-вторых, если fetchList — единственная мутирующая операция, то имеет смысл использовать observable.ref вместо observable.
С этим согласен
В-третьих, откуда вы взяли этот паттерн с оборачиванием Promise в другой Promise?! Зачем вообще внешний Promise нужен?
Конкретно в данном случае это не нужно, писал в спешке. Такую конструкцию Promise в Promise, я обычно использую когда неизвестно, какой статус от сервера может придти. Это может быть 200 или 400. И то и то нормально. Но если я потом буду ждать ответ в async он упадет, а в случае с двумя промисами у меня есть возможность прописать resolve даже если промис вернется не со статусом ОК.
В-четвертых, action не действует на асинхронные продолжения. Конкретно в приведенном вами коде декоратор action бессмысленный.
Оф документация:
The action wrapper / decorator only affects the currently running function, not functions that are scheduled (but not invoked) by the current function! This means that if you have a setTimeout, promise.then or async construction, and in that callback some more state is changed, those callbacks should be wrapped in action as well!
Почему — я выше подробно расписал. Голый MobX вы можете сравнить, скажем, с голым Svelte, с react hooks, с knockout и пр.
Я сравниваю преимущества MobX по сравнению с flux — архитектурой (на примере Redux) в приложениях на React. Оба они по сути конкуренты — и то и другое представляется как возможность организовать хранение данных на фронте. Статья так и называется — почему вы должны использовать MobX вместо Redux. Почему я должен сравнивать MobX с Svetle, Knockout и react hooks я, честно говоря не очень понимаю.
Согласен, такой подход позволяет убрать всю бизнес логику из компонентов, оставить в них только логику отображения. Тут тоже несколько плюсов:
1. Компоненты становятся меньше и соответственно более понятно, что в них происходит
2. Если в компонентах фигачить бизнес-логику, она будет пересчитываться каждый раз, когда этот компонент будет перерендериваться, а это минус к производительности
3. Компоненты становятся менее зависимыми от данных == больше шанс их переиспользовать.
Можно создать отдельный класс в котором будут данные и отдельный класс в котором будут методы. Лично я предпочитаю хранить и данные и методы для этих данных в одном классе: