Комментарии 24
Херня.
Пользуемся React, Routing. Всё остальное втопку, особенно Flux.
Пользуемся React, Routing. Всё остальное втопку, особенно Flux.
Ооо, эксперт, уровень «херня».
Нет, константин, в отличие от человека, работающего в фирме, которая не в состоянии сделать так, что бы почта доходила, мы разбираемся в том, с чем работаем, в том числе и с Реактом.
Если у вас есть проблемы или вопросы по Почте, просто напишите нам, или прямо мне на k.lebedev@corp.mail.ru, я всегда рад помочь. Ещё советую настроить postmaster, он способен устранить множество вопросов связанных с доставкой почты.
Макс, а чем тебе Flux не угодил-то? Как я понимаю опыт есть, расскажи о своём кейсе.
Очень просто: Flux это про глобальные переменные. Реакт сам по себе хорошая штука, но он прежде всего решает вопрос того, как спустить данные вниз и отрендерить. Вопрос того, как поднять наверх изменения в нём замазан и отдан на откуп фантазии девелопера.
Flux — это плохой пример, потому что предлагает использование глобальных переменных и получение данных в обход всей иерархии. Это плохо сказывается и на тестировании и на изоляции и на всём остальном.
Про Redux слышал, но не смотрел.
Я предпочитаю максимально до упора спускать коллбеки вниз, потому что это оказывается гораздо удобнее впоследствии. Не, можно конечно пользоваться «общей шиной данных», пока это не надо начинать тестировать.
Flux — это плохой пример, потому что предлагает использование глобальных переменных и получение данных в обход всей иерархии. Это плохо сказывается и на тестировании и на изоляции и на всём остальном.
Про Redux слышал, но не смотрел.
Я предпочитаю максимально до упора спускать коллбеки вниз, потому что это оказывается гораздо удобнее впоследствии. Не, можно конечно пользоваться «общей шиной данных», пока это не надо начинать тестировать.
согласен, то, что вы говорите имеет место в реакте. именно поэтому придумали smart & dumb components:
medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.fz5k5xx7j
medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.fz5k5xx7j
Как раз таки Flux это НЕ глобальные переменные, а свойства определенного Store. А Redux это глобальные переменные, так как там один стор на все приложение. Никто вам не мешает использовать и колбеки и Flux одновременно, вот только с колбеками особой независимости компонентов не получается.
А Redux это глобальные переменные, так как там один стор на все приложение
Ну и как бы к этому одному стору никто не имеет доступа кроме как компонент на верхушке иерархии. Каждому маленькому компоненту достается только то что ему нужно. Никаких глобальных вещей.
собственно redux это реализация flux, просто в redux у нас единый источник правды и композиция редьюсеров, которые формируют новое состояние (а там у нас есть целоя гора возможностей как чего сделать), а flux — это просто принцип мол «юзайте event sourcing и все будет хорошо»
Про Redux очень годные обучающие ролики от создателя egghead.io/series/getting-started-with-redux
В первых роликах по сути Redux пишется небольшими кусочками с нуля, что практически сразу приводит к пониманию что-когда-зачем-почему. Очень советую для быстрого «въезда» в технологию, тем более, что серия по времени не очень большая, но супер полезная.
В первых роликах по сути Redux пишется небольшими кусочками с нуля, что практически сразу приводит к пониманию что-когда-зачем-почему. Очень советую для быстрого «въезда» в технологию, тем более, что серия по времени не очень большая, но супер полезная.
Оказывается, на Хабре про это не писали :) Опубликовал… habrahabr.ru/post/275435
Грег Янг идею Event Sourcing-а форсит с 2005-ого года примерно, а используется в том или ином виде уже не первый десяток лет. Ну так, к слову.
Про Redux слышал, но не смотрел.
подход redux-а как раз таки решает проблему flux-а которую вы описываете. Все состояние приложение хранится в одном месте, и спускается вниз разделяясь для каждого конкретного компонента. А там уже много всего можно придумать. Компоненты же поднимают ивенты о том что надо что-то сделать вверх, и так все проходит строго по циклу. Удобно, просто тестить, но на простых проектах — оверхэд.
Все состояние приложение хранится в одном месте, и спускается вниз разделяясь для каждого конкретного компонента.А как там решают задачу когда компоненту нужно для себя что-то подгрузить с сервера, например когда в компонент пришел ид пользователя и нужно загрузить его имя с сервера?
Компоненты же поднимают ивенты
таких задач как бы нет, вот и все.
В компонент приходит уже готовый кусок состояния, который должен включать в себя имя пользователя. Ну то есть у нас есть одна жирная структура которая содержит в себе все. Далее каждому компоненту по мере углубления по иерархии достается все меньший и меньший кусок состояния.
Если компоненту вдруг понадобилось обновить состояние или поменять его — прокидываем в сервисы событие/действие, и далее ждем пока сверху у нас обновится состояние. Очень простая концепция которая невероятно упрощает махинации с UI.
Ну и да, состояние специфичное для view можно оставить внутри компонента, изолировано от внешнего мира. Не очень разумно при каждом смещении курсора прогонять все по кругу.
В компонент приходит уже готовый кусок состояния, который должен включать в себя имя пользователя. Ну то есть у нас есть одна жирная структура которая содержит в себе все. Далее каждому компоненту по мере углубления по иерархии достается все меньший и меньший кусок состояния.
Если компоненту вдруг понадобилось обновить состояние или поменять его — прокидываем в сервисы событие/действие, и далее ждем пока сверху у нас обновится состояние. Очень простая концепция которая невероятно упрощает махинации с UI.
Ну и да, состояние специфичное для view можно оставить внутри компонента, изолировано от внешнего мира. Не очень разумно при каждом смещении курсора прогонять все по кругу.
В компонент приходит уже готовый кусок состояния, который должен включать в себя имя пользователя. Ну то есть у нас есть одна жирная структура которая содержит в себе все.Вы же не предлагаете выкачивать всю БД на клиент, а значит вам нужно организовывать дополнительный код на (сервере и) клиенте который заботится о наличии данных именно для этого компонента.
Например ангуляр, когда в компоненте понадобится вывести имя пользователя, я например в этой же компоненте просто укажу фильтр
{{userId | getUserName}}. С Redux, получается, когда в этой компоненте нужно вывести имя, мне придется править какое-то третье место которое будет загружать доп. данные, т.е. появляется какая-то зависимость, что не хорошо.Ещё я получал такие ответы на этот вопрос от «сторонников» Реакта (не знаю что у них flux/redux/reflux или самопал):
* Компонент сам загружает и хранит локальный кеш для этих данных.
* Компонент сам загружает или отправляет ивент на загрузку, и доп. данные хранятся кешем в общем стейте.
Вы же не предлагаете выкачивать всю БД на клиент
Вы же не предлагаете выводить все данные на одной странице?
я например в этой же компоненте просто укажу фильтр
Как по мне это пример того как делать ненадо. А пример с айдишкой это скорее пример преждевременной оптимизации. Я обычно сразу прокидываю всю сущность юзера, а там уже компонент сам разберется что ему выводить. В вашем же случае мне надо будет в любом случае написать фильтр и сделать зависимость компонента от оного. Ну и в случае если мы просто состояние прокидываем тестировать это чуть проще.
Фильтры в angualr1 синхронные, и это накладывает определенные ограничения о том как они должны использоваться. В angular2 они у нас могут быть асинхронными но я все еще против загрузки данных из фильтров.
Компонент сам загружает или отправляет ивент на загрузку, и доп. данные хранятся кешем в общем стейте.
Компонент может прокинуть в сервисный слой информацию о том что надо поменять состояние. Как именно — поменять данные, обновить данные или просто загрузить — это не столь важно. Правда последнее кажется мне несколько странным. тут суть в том что бы у нас был единый источник правды, одно место которое всегда содержит актуальное состояние.
Вы же не предлагаете выводить все данные на одной странице?Данные можно подгружать по требованию, в случае с Redux видимо нужно отправлять ивент на подгрузку данных и сохранение их в общий стейт.
Я обычно сразу прокидываю всю сущность юзера, а там уже компонент сам разберется что ему выводить.Но в сущности юзера есть идентификатор босса и отдел, которые вдруг понадобилось вывести, теперь вам надо править загрузчик этих доп. данных и прокидывать их с самого верха.
В вашем же случае мне надо будет в любом случае написать фильтрУ меня в проектах такой фильтр обычно уже есть готовый и используется в разных местах, т.к. в SPA иногда нужно выводить имя по имеющемуся идентификатору, да и вообще можно без фильтра, главное — правим тот компонент который нужно поправить, а не ходим по всему проекту и правим в разных местах. Про тестирование тут не скажу, нужно сравнивать конкретные реализации.
но я все еще против загрузки данных из фильтров.Фильтр берет данные из сервисов — все норм, и это удобно т.к. не нужно писать костыли в контроллере.
Вы переметнулись на сторону Реакта или используете redux/flux с Ангуляром?
в случае с Redux видимо нужно отправлять ивент на подгрузку данных и сохранение их в общий стейт.
ну на самом деле никто этот момент не оговаривает особо. Можно так, можно эдак. Просто данные для текущего скрина долны лежать в одном сторе и потом спускаться вниз по иерархии. В целом посылать ивенты из компонентов тоже не ок, так как это подразумевает что бы запрашиваем данные и вся прелесть теряется. Данные уже должны быть.
В целом же я балуюсь пока только с этим, и просто использую схожую идею — один стор на приложение, который наполняется нужными для данного скрина данными. Что именно нужно решают ресолверы роутера.
Вы переметнулись на сторону Реакта или используете redux/flux с Ангуляром?
как я уже отметил выше — только балуюсь с редаксом, в продакшене у меня просто схожая концепция (прокидывание данных из ресолверов роутера вниз в компоненты). Ангуляр на реакт заменять не планирую, уж сильно мне нравятся декларативные шаблоны вместо операций с виртуальным домом. Мне банально удобнее это все тестить и вообще как-то веселее.
Вообще вы хорошие вопросы задаете, надо придумать кейсов. У меня пока все хорошо и все разделено тупо за счет роутера.
Flux — это плохой пример, потому что предлагает использование глобальных переменных
Что? В идее Flux ни чего не сказано о глобальных переменных.
А я вот посоветую хотя бы посмотреть в сторону clojurescript + reagent, код получается чертовски простым и прекрасным (хотя для незнакомых с lisp непривычным поначалу)!
React по сути своей очень функционален и его пересечение с функциональным clojure дает поразительный результат. Надеюсь, когда-нибудь соберусь таки написать об этом обзорную статью на хабр.
React по сути своей очень функционален и его пересечение с функциональным clojure дает поразительный результат. Надеюсь, когда-нибудь соберусь таки написать об этом обзорную статью на хабр.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
How to ReactJS