омг

мы же айди храним только

относится тем что многие жалуются на тормоза с редаксом из-за которого решают не хранить какие-то данные в сторе

относится тем что многие жалуются на тормоза с редаксом из-за которого решают не хранить какие-то данные в сторе

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

меняются только ссылки на объекты рекурсивно до изменившегося примитива, чему там тормозить?

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

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

меняются только ссылки на объекты рекурсивно до изменившегося примитива, чему там тормозить?

не меняются ссылки а пересоздаются, код {...task, comments: [...task.comments, {...comment, text: 'new text}]} создает новый объект таска и копирует туда все свойства, создает новый объект массива и копирует туда все текущие комментарии при этом если в массиве тысячу объектов то редаксу нужно перекопировать ссылки на все эти тысчячу объектов, и создает новый объект комментария который нужно изменить и копирует туда ссылки свойства которые не были изменены. И это только один уровень, а перед таском стоит проект с массивом тасков а перед проектом папка с массивом проектов. А теперь сравни с версией mobx-а : comment.text = 'newText' - ничего не создается, ничего не копируется

ну если чистый мобх, то он довольно быстро работает

но не хватает таких фич как в mst со всем деревом состояний

не меняются ссылки а пересоздаются, код {...task, comments: [...task.comments, {...comment, text: 'new text}]} создает новый объект таска и копирует туда все свойства, создает новый объект массива и копирует туда все текущие комментарии при этом если в массиве тысячу объектов то редаксу нужно перекопировать ссылки на все эти тысчячу объектов, и создает новый объект комментария который нужно изменить и копирует туда ссылки свойства которые не были изменены. И это только один уровень, а перед таском стоит проект с массивом тасков а перед проектом папка с массивом проектов. А теперь сравни с версией mobx-а : comment.text = 'newText' - ничего не создается, ничего не копируется

а, я тебя понял: если один элемент большого массива изменился, то это боль хм. Я даже не сталкивался с такими системами, где столько вложенности массивов

не меняются ссылки а пересоздаются, код {...task, comments: [...task.comments, {...comment, text: 'new text}]} создает новый объект таска и копирует туда все свойства, создает новый объект массива и копирует туда все текущие комментарии при этом если в массиве тысячу объектов то редаксу нужно перекопировать ссылки на все эти тысчячу объектов, и создает новый объект комментария который нужно изменить и копирует туда ссылки свойства которые не были изменены. И это только один уровень, а перед таском стоит проект с массивом тасков а перед проектом папка с массивом проектов. А теперь сравни с версией mobx-а : comment.text = 'newText' - ничего не создается, ничего не копируется

так это в твоей версии стора так хранится одна сущность внутри другой, ничто не мешает хранить индексы параллельно друг другу (ну как в базе таблицы с сылками по id), тогда изменение таска в твоем примере не повлечет за собой изменение проекта

ребят, не начинал нового проекта на реакте уже год. Где почитать про что сейчас круто. Как насчет: -рутер для сервера и клиента -что-нибудь к mobx для нормализации -koa умерла? -сжималка/обфускатор к вебпаку Может стартер кит есть готовый? Я брал тот что от nightwolfz последний раз

create react app

ребят, не начинал нового проекта на реакте уже год. Где почитать про что сейчас круто. Как насчет: -рутер для сервера и клиента -что-нибудь к mobx для нормализации -koa умерла? -сжималка/обфускатор к вебпаку Может стартер кит есть готовый? Я брал тот что от nightwolfz последний раз

давно в телеграме тебя не видел)

create react app

мне с SSR надо

хм

так это в твоей версии стора так хранится одна сущность внутри другой, ничто не мешает хранить индексы параллельно друг другу (ну как в базе таблицы с сылками по id), тогда изменение таска в твоем примере не повлечет за собой изменение проекта

ок, с нормализацией у нас будет примерно такая схема state = { tasks: { .... 2123: {id: 2123, name: 'task1', comments: [23, 444, 22]} }, comments: { ... 23: {id: 23, text: 'comment1'} } }тогда да, при изменения комментария нужно будет обновить только комментарий а поскольку task хранит айдишники его менять не нужно. Но проблема остается! Как мы меняем состояние когда нужно обновить комментарий? Делаем обычно такое newState = {...state, {comments: {...state.comments, 23: {...state.comments[23], text: 'new text'}}}} - пусть и в меньшем размере но имеем точно такую же проблему - при изменении одного поля text в комментарии нам нужно создать новый объект комментария перекопировать все остальные поля комментария, создать новый объект хеша и перекопировать ссылки на все остальные комментарии - причем не только текущего юзера а вообще все - а это могут быть тысячи комментариев ну и также нужно будет создать новый рутовый объект состояния и перекопировать туда ссылки на все обекты-хеши

immutable)

вообще это не проблема, у меня редьюсер только ложит в стор данные которые прислал normalizr

ок, с нормализацией у нас будет примерно такая схема state = { tasks: { .... 2123: {id: 2123, name: 'task1', comments: [23, 444, 22]} }, comments: { ... 23: {id: 23, text: 'comment1'} } }тогда да, при изменения комментария нужно будет обновить только комментарий а поскольку task хранит айдишники его менять не нужно. Но проблема остается! Как мы меняем состояние когда нужно обновить комментарий? Делаем обычно такое newState = {...state, {comments: {...state.comments, 23: {...state.comments[23], text: 'new text'}}}} - пусть и в меньшем размере но имеем точно такую же проблему - при изменении одного поля text в комментарии нам нужно создать новый объект комментария перекопировать все остальные поля комментария, создать новый объект хеша и перекопировать ссылки на все остальные комментарии - причем не только текущего юзера а вообще все - а это могут быть тысячи комментариев ну и также нужно будет создать новый рутовый объект состояния и перекопировать туда ссылки на все обекты-хеши

mobx state tree нашел, вроде это сейчас пушка. Единственный минус - нужно дефинировать все сущность заново в клиенте, ну и с чистым мобксом еще больше работы: https://github.com/kriasoft/react-starter-kit Может с GraphQL с какой либой это все из коробки работает?

mobx state tree нашел, вроде это сейчас пушка. Единственный минус - нужно дефинировать все сущность заново в клиенте, ну и с чистым мобксом еще больше работы: https://github.com/kriasoft/react-starter-kit Может с GraphQL с какой либой это все из коробки работает?

https://medium.com/front-end-developers/a-look-at-relay-and-apollo-96fcb215e1d

Вот посвежее https://medium.com/@wonderboymusic/upgrading-to-relay-modern-or-apollo-ffa58d3a5d59

https://medium.com/front-end-developers/a-look-at-relay-and-apollo-96fcb215e1d

>2016 Тогда помню не было straightforward way в релее как-то роли юзеров разграничивать

Ни у кого небыло проблем с добавлением других лоадеров в babelrc если уже есть emotion. У меня такой babelrc конфиг { "presets": [ "next/babel" ], "plugins": [ [ "emotion", { "inline": true }, "inline-import-data-uri" ] ] } и последний лоадер не подключается почему то, emotion отключаю все нормально работает.

ок, с нормализацией у нас будет примерно такая схема state = { tasks: { .... 2123: {id: 2123, name: 'task1', comments: [23, 444, 22]} }, comments: { ... 23: {id: 23, text: 'comment1'} } }тогда да, при изменения комментария нужно будет обновить только комментарий а поскольку task хранит айдишники его менять не нужно. Но проблема остается! Как мы меняем состояние когда нужно обновить комментарий? Делаем обычно такое newState = {...state, {comments: {...state.comments, 23: {...state.comments[23], text: 'new text'}}}} - пусть и в меньшем размере но имеем точно такую же проблему - при изменении одного поля text в комментарии нам нужно создать новый объект комментария перекопировать все остальные поля комментария, создать новый объект хеша и перекопировать ссылки на все остальные комментарии - причем не только текущего юзера а вообще все - а это могут быть тысячи комментариев ну и также нужно будет создать новый рутовый объект состояния и перекопировать туда ссылки на все обекты-хеши

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

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

так удобней хранить и работать именно со вложенными объектами - не нужно создавать контейнеры чтобы замапить айдишники на объекты, не нужно обмазываться постоянными простынями mapStateToProps, достаточно просто вывести<div>{task.comments.map(comment=><Comment comment={comment}/>)}</div> и компонент комментария получит не айдишник а сразу объект и может просто вывести <div>{this.props.comment.text}</div>. и не нужно никаких mapStateToProps. Или вот нужно например в компоненте комментария отреднерить имя папки - с айдишниками нам нужно вытаскивать несколько раз родительские объекты - state.folders[state.projects[state.tasks[comment.taskId].projectId].folderId].name чтобы добраться до папки, когда же в мобиксе можно просто пройтись по ссылками и это намного чище и проще выглядит - comment.task.project.folder.name

Кстать, а что думаете про https://cerebraljs.com/docs/api/index.html ?

так удобней хранить и работать именно со вложенными объектами - не нужно создавать контейнеры чтобы замапить айдишники на объекты, не нужно обмазываться постоянными простынями mapStateToProps, достаточно просто вывести<div>{task.comments.map(comment=><Comment comment={comment}/>)}</div> и компонент комментария получит не айдишник а сразу объект и может просто вывести <div>{this.props.comment.text}</div>. и не нужно никаких mapStateToProps. Или вот нужно например в компоненте комментария отреднерить имя папки - с айдишниками нам нужно вытаскивать несколько раз родительские объекты - state.folders[state.projects[state.tasks[comment.taskId].projectId].folderId].name чтобы добраться до папки, когда же в мобиксе можно просто пройтись по ссылками и это намного чище и проще выглядит - comment.task.project.folder.name

Не нужно смешивать разные вещи, есть хранение к данных, есть доступ к ним, есть их рендер. До этого мы о говорили о хранении, сейчас внезапно перешли на доступ, с чего бы?

Не нужно смешивать разные вещи, есть хранение к данных, есть доступ к ним, есть их рендер. До этого мы о говорили о хранении, сейчас внезапно перешли на доступ, с чего бы?

это же взаимосвязано, ограничения редакса и необходимость хранить айдишники вместо объектов несет кучу неудобств работы на уровне рендера в компонентах

это же взаимосвязано, ограничения редакса и необходимость хранить айдишники вместо объектов несет кучу неудобств работы на уровне рендера в компонентах

Пусть будет так )

Нет, всё таки прихожу к выводу, что Redux для подавляющего числа веб приложений - это не очень хорошая вещь.

а для больших?)

А я попробовал redux-act и сижу радуюсь теперь

а для больших?)

думаю, что даже для больших он не очень видимо он для особо специфичных, когда одно действие может очень сильно изменить стейт (например совершенно разные части стейта) но я что-то не могу придумать пример такого приложения

думаю, что даже для больших он не очень видимо он для особо специфичных, когда одно действие может очень сильно изменить стейт (например совершенно разные части стейта) но я что-то не могу придумать пример такого приложения

У меня такое везде

один экшен апдейтит много редьюсеров сразу

в любом случае всё равно уж больно много кода поулчается, даже с redux-act

У меня такое везде

а что за приложение, если не секрет?

телеграм на реакте

а разве в mobx state tree нельзя то же самое сделать

то есть обновлять разные куски стейта

от одного экшена

ну не знаю, мне кажется что для телеграма можно и не реагировать кучей редьюсеров на один экшн, но я могу и ошибаться

а разве в mobx state tree нельзя то же самое сделать

думаю, что можно

там API требует такого

а

ERROR: S client not available

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

понял

Можно конечно разбить на много экшенов

Но это еще больше кода писать)

просто мне кажется, что для подобных штук редакс как раз будет удобнее, чем mobx или mobx-state-tree

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

надеюсь mobx наберёт хорошую такую популярность, чтобы потеснить redux, а то как мне кажется многие пихают redux во все приложения, потому что это стильно-модно-молодёжно и альтернатив особых не было раньше (Flux не берём в расчёт)

хотя mobx тоже не идеален

ну просто я уже костыли начинаю пилить для нормализации/денормализации, @zerobias там уже какую-то свою штуку поверх редакса пилит

это тоже нехорошо

я вообще считаю, что нормализация не нужна

это же не СУБД

мне кажется надо бд обычную на фронт)

а вот не надо нихрена

именно что не надо

потому что СУБД хороша на больших объёмах данных, которых на фронтенде нет и не будет

ну редакс вполне себе бд уже со всеми этими ids byId

на фронте всё спокойно размещается в оперативе

потому что СУБД хороша на больших объёмах данных, которых на фронтенде нет и не будет

телеграм вполне большие объемы

на фронте всё спокойно размещается в оперативе

а

так я про in memory db

Именно нормализация/денормализация и язык запросов для редакса, без ререндеров