дык есть апи

1. У вас есть store который содержит некие сущности (entities) 2. У вас есть reducer-ы, которые позволяют осуществлять менеджмент этих сущностей на основе обробатываемых actions 3. У вас есть actionCreators, которые позволяют производить асинхронные запросы, делать вычисления и в конечном итоге делать dispatch в store некоторых action, что в последствии меняет state 4. У вас есть селекторы (selectors) которые позволяют на основе входых параметров взять часть state сделать преобразование и на выходе получить нормализованные данные для каких-то нужд 5. У вас есть react-redux и метод connect, который позволяет используя методы mapStateToProps и селекторы спроецировать state на props компонента и mapDispatchToProps, чтобы спроецировать набор actionCreators на props

Да

все 5 да

Сответственно настроив оперделенные правила селекторов вы получаете фильтрацию

для новичка и не только рекомендую изучение официальной документации, прочитать которую будеть легче после курса по изучению частотного англо-русского словарика. В состав которого вошли 2553 выбраных из официальной документации React и React Native слов, изучение которого легче с мобильным приложением Memrise https://www.memrise.com/course/1450006/react-react-native/ Сделал для себя, если найдете ошибки пишите, пофиксю.

для новичка и не только рекомендую изучение официальной документации, прочитать которую будеть легче после курса по изучению частотного англо-русского словарика. В состав которого вошли 2553 выбраных из официальной документации React и React Native слов, изучение которого легче с мобильным приложением Memrise https://www.memrise.com/course/1450006/react-react-native/ Сделал для себя, если найдете ошибки пишите, пофиксю.

сразу видно, программист пост составлял

так вот вопрос. Если есть какая то кнопка фильтрации/ сортировки. Где лучше эту фильтрацию сартировку проводить?

Зависит от объема данных. Большой объем данных лучше сортировать на сервере - и выдавать результат, т.к. в противном случае, придется слать большой объем данных клиенту, который просто будет занимать место. Если же количество данных необходимо всегда пользователю в полном объеме (например, список его задач на текущий момент), то конечно нет смысла сортировать задачи по типу на сервере. Нужно сортировать на клиенте, т.к. высока вероятность того, что пользователю понадобятся все данные.

Я делаю так: в момент выбора фильтра посылаю запрос к серверу и одновременно с этим оптимистично фильтрую на клиенте. От сервера потом могут прийти уточнённые данные, список перерендрится

странноватая логика. Я всегда точно знаю, могу я получить точный результат исходя из имеющихся данных - или нет. Поэтому, если я могу получить точный результат без сервера - я его получаю. Если нет - жду ответ от сервера. Иначе, получается, что пользователь попросит выбрать ему красивых девушек, а мы, "оптимистично", выдадим ему обезьян. А что - девушки же. Пользователь может и обидеться.

Можно и более реальны пример привести, с городами. Мы вводим "Москва", а нам, оптимистично, выдает "Нью-Йорк". Разве не странное поведение?

1. У вас есть store который содержит некие сущности (entities) 2. У вас есть reducer-ы, которые позволяют осуществлять менеджмент этих сущностей на основе обробатываемых actions 3. У вас есть actionCreators, которые позволяют производить асинхронные запросы, делать вычисления и в конечном итоге делать dispatch в store некоторых action, что в последствии меняет state 4. У вас есть селекторы (selectors) которые позволяют на основе входых параметров взять часть state сделать преобразование и на выходе получить нормализованные данные для каких-то нужд 5. У вас есть react-redux и метод connect, который позволяет используя методы mapStateToProps и селекторы спроецировать state на props компонента и mapDispatchToProps, чтобы спроецировать набор actionCreators на props

а не наоборот? Встречал рекомендацию как раз нормализованный стейт делать, а вот уже его при экспорте данных, через селекторы конвертить в json-дерево

Наоборот, что именно?

Упс, всё процитировалось. Имел в виду пункт 4

Упс, всё процитировалось. Имел в виду пункт 4

Нормализация процесс относительный от субъекта использования данных. В state данные нормализованы относительно логики работы reducer. selector-ы и mapStateToProps позволяет сделать нормализацию относительно субъекта (Компонента) их использующих.

Логично. Я почему прицепился - ну вот лично у меня не получается юзать стейт который плоский прям как БД. 2-3 уровня иерархии точно есть и это удобно

Для переиспользуемой архитекутры flatten state - обязательное условие. Когда мы говорим о сущностях БД. Могут быть отдельные разделы дерева, которые отражают не состояние сущностей. Там может быть достаточно сложная структура.

и что-то парит меня эта ситуация. Наверное при нагрузке это выльется в оверхед от постоянного JSON.parse(JSON.stringify(state)) в редьюсерах

Мммм..

Это позволяет максимально просто сделать кэширование и мэпинг dataToObject.

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

Все верно.

можно было добавить PreJSS но я забыл))

Я это запомню ?

И для клиент-серверного взаимодействия стоит обратить внимание на GraphQL - это избавит от изобретения велосипедов в redux с обработкой хотя бы своего взаимдействия с сервером.

Многие проекты напрямую не работают с redux, а используют его как точка интеграции набора библиотек использующих через middleware redux.

Чем плохо выделить шаренный код (редьюсеры и action creator'ы) в отдельный проект, подключить и на клиенте и на сервере и гонять голые actions json'ами по сети? Вполне себе взаимодействие, вполне себе синхронизированное состояние (ну или его общая часть)

Правда, тогда redux нужен и на сервере и на клиенте. Но опять же всю логику на нем можно и не делать

А зачем редакс на сервере?

redux и так делается и на сервере зачастую и на клиенте, по крайней мере для компонент при SSR он нужен.

Чем плохо выделить шаренный код (редьюсеры и action creator'ы) в отдельный проект, подключить и на клиенте и на сервере и гонять голые actions json'ами по сети? Вполне себе взаимодействие, вполне себе синхронизированное состояние (ну или его общая часть)

Чем плохо - причин много: 1. Это синхронизация по сути, где у вас будет при одном клиенте один сторе на сервере. При 1000 - 1000 2. Это ограничения по правам доступа 3. Это механизмы кэширования, которые можно написать заново, но зачем если уже все написано

Потеря в масштабируемости для балансировки и проксирования запросов API.

Как эксперимент - почему нет! )

А зачем редакс на сервере?

Везде, где есть стейт, будет удобен редакс. Если на сервере нужно держать стейт, имеем право.

Не просто имеем право, а имеем необходимость для SSR.

Ну, я сейчас не только в контексте вебапп говорю, а вообще.

Допустим, нужно бота поднять на ноде для телеги.

В голове есть уже готовые паттерны, реализация которых встанет как родная.

Насчет graph-ql. Согласен что есть все эти проблемы - кэш, аутентификация, балансировка. Но вот читаю про graph-ql - это тупо язык запросов. Какое он имеет отношение ко всем этим инфраструктурным проблемам...

Насчет graph-ql. Согласен что есть все эти проблемы - кэш, аутентификация, балансировка. Но вот читаю про graph-ql - это тупо язык запросов. Какое он имеет отношение ко всем этим инфраструктурным проблемам...

помоему graph-ql не нужен если ты не фейсбук.

всмысле если у тебя масштабы и сложность не шкалит

Насчет graph-ql. Согласен что есть все эти проблемы - кэш, аутентификация, балансировка. Но вот читаю про graph-ql - это тупо язык запросов. Какое он имеет отношение ко всем этим инфраструктурным проблемам...

Просто берем конкретную реализацию, например apollo-stack и видим как там все решено.

Например у нас из простых конфигурационных файлов автоматически генерируется backend - БД + GraphQL API - front-end GraphQL API - CRUD + subscription и это очень лаконично.

Каждый модуль выглядит примерно так:

Интеграция же с компонентами делается посредством HOCFactory с заданием нужных параметров генерации запросов, где делать запросы и мутации, делать ли polling и прочие параметры.

Так же большим плюсом GraphQL является передача типа сущностей внутри ответа, что позволяет делать синхронизацию кэша даже из побочных ответов севера.

В общем суровый Ынтырпайз. Спасибо за ликбез :)

Enterprise не Enterprise, но чертовски удобно! )

помоему graph-ql не нужен если ты не фейсбук.

Даже для очень маленького приложения graphql очень удобен

Везде, где есть стейт, будет удобен редакс. Если на сервере нужно держать стейт, имеем право.

Ужасные вы люди. Создаете проблемы, а потом решаете их.

В соседней конфе смотрите какие люди! )

А что за конфа? :)

Известный факт, самое большое react сообщество - https://www.reactiflux.com/

Хочу посмотреть как они свой dnd объяснять будут

Даже для очень маленького приложения graphql очень удобен

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

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

Какую реализацию использовали?

Discord какой-то хотят, не телегу

Discord - это серьезный аппарат для подобных конференций.

Telegram отдыхает.

Верните irc пожалуйста xD

Вы можете запустить его в браузере.

Это изначально альтернатива TeamSpeak для геймеров.

А дальше разрослось.

Вы можете запустить его в браузере.

хм

slack для геймеров я бы сказал

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

забыл какой

ERROR: S client not available

Да, описание в аппсторе - чат для геймеров . Все оч серьёзно , ставлю

Слак.

Какую реализацию использовали?

relay и сопутствующее

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

telegram например

а я про что

relay и сопутствующее

Действительно после Relay может сложиться такое мнение.

Действительно после Relay может сложиться такое мнение.

Какие будут рекомендации?

Действительно после Relay может сложиться такое мнение.

а что ок, apollo какой-нибудь?

Я уже писал выше про него. Да.

У меня сделана реализация с множественными подсистемами, каждая из которых имеет свою GraphQL схему и свой datastore => через sequelize и свой сервер подисок через ws.

И это летает и очень компактно.

Apollo я так понял это для фронтенда, а на сервере что используете?

Его же. У них в стэке есть и серверная часть.

Сразу скину middleware сюда, чтобы было на чем базировать.

Ужасные вы люди. Создаете проблемы, а потом решаете их.

Ващета нет.

https://gist.github.com/lokhmakov/ed6170cb085d070aa22bad44528e53e4

Ващета нет.

Ноду на сервере только ужасные люди используют.

middleware комплексный, возьмите только базовые вещи без множественных схем.

Так же в моем примере processGraphiQL вытащенная реализация из их исходников, под наши нужды. Вам можно использовать настроку endpoint в graphqlExpress.

)

https://gist.github.com/lokhmakov/ed6170cb085d070aa22bad44528e53e4

а зачем там graphiqlExpress если он не используется?

Недавно избавились от этой зависимости, import не убрали

а, понял

сильно ли критично не выносить проверку прав в модели, а делать это в резолверах?

Обычно это делается либо перед резолвером, либо в резолвере.

Контекст пользователя добавляется до middleware graphql

И уже потом передаётся в каждый резолвер

Ограничение прав делается на основании названия запроса, его параметров и контекста

Ноду на сервере только ужасные люди используют.

Так говорят только религиозные фанатики, которые ничего не понимают.

ну это понятно. в резолвере делать не советуют, а советуют передавать контекст в модель, типо User.update(user, context.user)

типо если есть еще и другие api, rest например