Дзен не позвонит
Комментарии (3)
raveclassic
7 июня 2017 в 18:26
+1↑
↓
Вы уж простите, но выглядит как очередная истерика.Сравнения с первым ангуляром вызывают сомнения.
Одной фразой «написали бизнес-логику»? А как же отдельные файлы под сервисы, под модули, связать это все потом?
Редьюсеры, экшены и мидлвари для компонентов? Ну так не пишите, это то же самое «написали бизнес-логику», только гранулярно и в разных файлах. Не нравится — пишите прямо в компоненте. Вся асинхронщина прекрасно кикается в componentWillUnmount.И нет, не должно все оседать в middleware, middleware лишь процессит передаваемые в нее действия.
И нет, не нужен редьюсер на каждый чих, редьюсеров должно быть минимальное количество, стейт должен быть компактен и не раздут, и все необходимое выводится через селекторы.Возможно пора двигаться дальше, посмотреть как все эти проблемы решали до нас более зрелые стеки?
Так и решали: redux это пародия на CQRS+ES, прекрасно применяемые в огромных приложениях. А в качестве process-managers выступают саги.Будущее
Компоненты контейнеры
Контейнеры — не компоненты с бизнес-логикой, а CQRS-обертка.Selectors — ORM. И да, нам нужны не только getters, но и setters;
Нет, не так. Селекторы/геттеры — cQrs, экшены/сеттеры — Cqrs.Нам нужен стандарт, но уже не «frontend», а Универсального Приложения, работающего везде, от унитаза, до космического корабля?
Но ведь и так уже все работает же?7 июня 2017 в 18:35
0↑
↓
Да, Вы абсолютно правы, это моя истерика, не более того.
Fen1kz
7 июня 2017 в 18:47 (комментарий был изменён)
+1↑
↓
Лол, а я как раз подумываю написать статью, что redux это счастье. Видимо мое удовольствие от работы === удовольствию Дена и === отсутствию магии.
Для меня крутость redux в детерменированности и декларативности.
Декларативность (в очень вольном толковании смысла этого слова) — в отличие от «дергания» каких-то функций и методов с какими-то побочными эффектами, redux дает простую кнопку «отправить action».
То есть на предыдущих фреймворках или вашем любимом jquery вы писали методы, за которые потом «дергали» и старались все это дело как-то упорядочить, то в redux эта структурированность из коробки. Всю побочку вы описываете в middleware или action creator’ах. Вся работа с данными приложения — ТОЛЬКО через reducer’ы. (А ваше желание «setter«ов демонстрирует полное непонимание самой идеи redux)
Я не беспокоюсь что что-то сломается когда я делаю dispatch (action), в отличие от, скажем, вызова метода сервиса ангуляра. Потому что самого сервиса больше нет и вся обработка бизнес логики структурированно находится в одном месте, а не размазана по куче этихъ самых сервисов.
И детерменированность — В каждый конкретный момент времени я знаю что именно повлияло на мои данные. Никаких «а вон в той не очень хорошо написанной директиве сработал $scope.$on () и что-то поменял в модели». No way. Более того, кроме этого осознания, я ещё и правда могу удобно посмотреть и отследить все действия, которые и привели к данному состоянию модели.
Это очень светлое ощущение чистоты кода, когда ты понимаешь, что само по себе ничего не произойдет, что бы там юзер где бы не кликал или что бы сервер не прислал.
А если это был просто истеричный инфоповод для идеи вашего Универсального Приложения — то, пожалуйста, посмотрите сюда: http://xkcd.ru/927/
