Но при этом все в глобальном сторе. Это как делать валидацию формы через запросы к бэку всегда, вместо валидации на фронте и на бэке. Зато one source of truth.

@draedful +1

что плохого в валидации на бэке?

Как подменить контекст в компоненте? Вот тут стор редукса передается через context, мне надо подменить в нем кое-что https://github.com/makeomatic/redux-connect/blob/master/modules/components/AsyncConnect.js

что плохого в валидации на бэке?

То, что валидировать можно в риалтайме и не всегда делать запросы.

Чуваки, я всегда знал что JS отстает от всего мира разработки, но не на столько же. Все же знают про паттер God Object ? Так вот - это антипаттерн номер 1 И тут встает вопрос, зачем вы его используете

db = god object?

Глобальный стейт - для состояния системы в целом. Если он начнет отвечать за все компоненты системы - то управлять им будет намного сложнее

ну эт от требований зависит

Кроме того DB разделена на таблицы/документы/ноды. Так что там так же есть свои разделения. DB - провайдер.

Как подменить контекст в компоненте? Вот тут стор редукса передается через context, мне надо подменить в нем кое-что https://github.com/makeomatic/redux-connect/blob/master/modules/components/AsyncConnect.js

если точнее, мне нужно в миддлваре знать, что dispatch вызывается из этого компонента

ну я бы так не сказал

Глобальный стейт - для состояния системы в целом. Если он начнет отвечать за все компоненты системы - то управлять им будет намного сложнее

this.

В сторе имхо должно быть только то, что требуется для нескольких компонентов из разных частей приложения, чтобы не пробрасывать от парента руками.

А данные?

так, ок, и в чем разница между стэйтом и данными?

Ни в чем имхо

я вот не понял аналогию, глобальный стэйт и db

это одно и то же

у тебя всегда есть стэйт

в любой момент времени

и либо он размазан

либо в одном месте

и когда ты активно разрабатываешь ты не знаешь когда тебе могут понадобится какие то данные

из другой части системы

и это ведет к связанности

если это не в сторе

где ты как раз абстрагируешься от этого

и когда ты активно разрабатываешь ты не знаешь когда тебе могут понадобится какие то данные

Some common rules of thumb for determing what kind of data should be put into Redux: Do other parts of the application care about this data? Do you need to be able to create further derived data based on this original data? Is the same data being used to drive multiple components? Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)? Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?

Взять тот же любимый всеми пример с дропдауном. У тебя сотня дропдаунов в приложении и приложению пофиг на то, открыты ли они. Если вдруг появляется один дропдаун с бизенс логикой, который на открытие что-то еще снаружи меняет - сделай флажок в сторе, за которым будешь следить и меняй его при открытии.

Тут вопрос стоял просто иначе "насколько мелкие события имеет смысл обрабатывать через Redux")

Все согласны про дропдаун

@BananaBobby про дропдаун мы уже все выяснили, и говорю, это исключение из правил

Насколько больше должно быть что-то, чтобы попасть в стейт

стор*

лично я пишу все в стор, за исключением того, когда понятно что затраты на это того не стоят. скажем тот же дропдаун

В остальном ты можешь делать как тебе удобнее и выбирать, что важнее. Или удобно все переписывать или сидеть со стором нормального размера.

и то, например на модалки у меня в сторе хранятся

@BananaBobby про дропдаун мы уже все выяснили, и говорю, это исключение из правил

У нас есть чат, на 3000 сообщений, любое сообщение может быть отредактировано, но в один момент времени должно редактироваться только 1 сообщение. Должен ли я хранить идентификатор сообщения в сторе или в локальном стейте родительского компонента?

В сторе конечно

В сторе конечно

Почему?

Флаг туда еще

потому что это связь

все паттерны, практики, внедрения перевнедрение зависимостей, возникают только с целью переиспользования , если дропдаун или цвет кнопки зависит только от состояния компонента, то зачем в стор то пихать

потому что это связь

между чем?

Я бы держал в сторе хоть какое-то упоминание о том, что сообщение редактируется.

В завимисости от этого может меняться интерфейс других компонент

В завимисости от этого может меняться интерфейс других компонент

Если есть связи, то лучше их выносить

Ну так и рефакторить когда он действительно нужен будет, интересней вопрос как группировать стор? скажем только по рутовым компонентам или по сущностями, или еще как то

Куда?

к тому же сращивать локальный стэйт и стор это та еще муть. все наверно видели ужасный хук componentWillReceiveProps когда переписывается локальный стэйт

Так и до корня приложения дойдет. В общем мы дойдем до того, что редакс не нужен)

ну вообще стор не должен зависить от интерфейса

это доменная модель

и она должна быть нормализована

блин, это же как база данных

блин, это же как база данных

+

есть селекторы, в которых ты приводишь данные в нужный вид по связям

И по сущносятм разбито все на первом уровне

кстати, было тут про God Object

щас только допер

кстати, было тут про God Object

БЛЯТЬ УРА

как бы стэйт не принимает никакие решения

а смысл God Object-а в том что он принимает решения

это просто тупо данные

так что я имел ввиду что компонент который держит в себе данные и как то манипулирует ими то он берет на себя слишком много

ERROR: S client not available

а вот если дропдаун по клику делает http-запрос и подгружает список стран? В стор?

а че это он сам http-запрос дергает?

он что в себе доменную логику содержит что ли)

например, если след раз кликнул, то надо снова подгружать или нет?

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

ну я не знаю как с ангуляром конечно, но у меня сразу родился кейс, два таких дропдауна на разных страницах

ну или нужно делать через Action'ы

так что конечно стор

Привет всем! Сложно ли подружить react-router с Laravel?

ну, если на нем написать только REST API , то почему нет

Если просто переходить по ссылкам то роутер нормально отрабатывает, но если обновить страницу через f5, то Laravel выкидывает ошибку NotFoundHttpException

Ну так и рефакторить когда он действительно нужен будет, интересней вопрос как группировать стор? скажем только по рутовым компонентам или по сущностями, или еще как то

Кажется, вот эта статья про это: https://github.com/reactjs/redux/blob/master/docs/recipes/reducers/NormalizingStateShape.md

@vladonxp а он точно все url-ы кроме апихи на / переводит где index.html отправляется?

Yuri Во годно, спасибо) Сами так же группируете?

пытаюсь, ага

@vladonxp а он точно все url-ы кроме апихи на / переводит где index.html отправляется?

к сожалению у меня туговато с конфигурированием htaccess

в корне лежит .htaccess

<IfModule mod_rewrite.c> RewriteEngine On RewriteRule ^(.*)$ public/$1 [L] </IfModule>

все запросы уходят на public

давайте конфигурирование апача/нгинкса вынесем за пределы чата

вот из того же разряда статья https://hackernoon.com/avoiding-accidental-complexity-when-structuring-your-app-state-6e6d22ad5e2a#.4xv0orw77

это ни реакт, ни около реакт и даже ни го

давайте конфигурирование апача/нгинкса вынесем за пределы чата

ну это же относится и к react-router

кмк, конфигурирование сервера не относится

я почти на 100% уверен что это дело в сервере

вот из того же разряда статья https://hackernoon.com/avoiding-accidental-complexity-when-structuring-your-app-state-6e6d22ad5e2a#.4xv0orw77

ага, похожая. Ну я так понимаю, что общее соображение должно быть такое, что надо делать структуру поплощще и предусматривать постоянные копирования и конкатенации в массивах.

Где лучше хранить массив со списком городов. В редюсере или в том же классе, где будет выводиться этот список?

Даже, где правильней

Городов - в редьюсере

ok

/stat@combot

combot.org/chat/-1001032883247