А ну мб

нужно лишь отслеживать их изменения (привет, mobx)

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

а то найдутся умельцы-идиоты, которые ORM запилят поверх этой СУБД

redux orm))))

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

хм

можешь развернуть? Как хранить в редаксе без нормализации?

или это конкретно про mobx

думаю, что никак

хотя

можно денормализованно хранить

хотя это так себе

просто стор редакса - это дерево со всеми его ограничениями

никаких циклических ссылок

да ещё и иммутабельность

ну так как решить траблу с вложенными данными при этом не делая нормализацию ?

ну так как решить траблу с вложенными данными при этом не делая нормализацию ?

два варианта всего: денормализация или циклические ссылки

и как это поможет трекать изменения ?

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

и как это поможет трекать изменения ?

трек изменений - это вообще отдельная задача

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

в редаксе это как раз не очень удобно сделано

Зато мобх тяжелее дебажить и репродьюсить

Зато мобх тяжелее дебажить и репродьюсить

mobx state tree, насколько я знаю, решает эти проблемы

даже с redux-devtools интегрируется

да, но из-за него оверхед в разы возрастает

инит тайм большой

куча ограничений

с типизацией

либы для мобх с ним не работают

в редаксе это как раз не очень удобно сделано

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

да, но из-за него оверхед в разы возрастает

сомневаюсь, что там оверхед такой уж большой

перед выбором между мобх и редаксом для проекта

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

на среднем для проекта обьекте

и на сколько миллисекунд тесты медленнее для mobx-state-tree были?

и он инитился оч долго

и он инитился оч долго

две минуты?

редукс с нормализаций 60мс а мобх стейт три 500

ну чёт долго, да

при это на клиент еще оверхед в виде 130 кб

конечно дальше оно быстрее работало с мобх

это не так много на самом деле, даже для мобильного инета

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

плюс редукс по размерам меньше весит и не привности такого большого оверхеда

Но вот если пилить что-то типа црмки, то тут лучше мобх

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

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

с его механизмом подписок осторожно надо обращаться

я когда игрался с ним, то выстреливал себе в ногу из-за этого

редукс с нормализаций 60мс а мобх стейт три 500

а на камом бенчмарке меряли? можно пример?

benchmark.js и плюс руками тестили примерно похожий код

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

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

смотря что делаешь

я имею ввиду код теста, какие компоненты, какое состояние

та просто закинули в бенчмарк жс createState и mst.create()

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

Если код теста закрыт и тут его не показать, то могу попробовать предложить померять вариант с использованием простого общего мутабельного состояния с вложенностью (как я выше писал) - точно такое же как в мобиксе но только без всяких обзерваблов и без всякого мобикса и когда нам нужно что-то изменить мы меняем свойство - comment.text = 'new text' и вызываем update() - функцию которая делает перерендер всего приложения - ReactDOM.render(<App/>, rootEl). У меня есть мысль что оверхед на работу состояния будет большим чем чистые мутируемые объекты и перерендер(точнее перепроверка потому что виртуал-дум) всего приложения будет быстрее

я не говорю про работу и перерендер

а просто про инит тайм

тем более если инит тайм - мобиксу ведь нужно на каждое свойство поставить геттеры и сеттеры и создать внутренние обзерваблы

у нас такая специфика была что перерендер особо не был критичен

а важно было инит тайм и вес

а важно было инит тайм и вес

в этом варианте стейт-мененджера вообще нет, так что по весу это лучший вариант) и инит тайм будет быстрее чем с мобиксом

ну как бы у нас в старом проекте такое и было

самописнео

и его тяжело дебажить и поддерживать

и его тяжело дебажить и поддерживать

Блин, ну что значит дебажить и поддерживать - все точно такое же как с мобиксом но только без декораторов и мобикса, вот из примера выше - состояние точно такое же const AppState = new class { width; height; ..... user = new User(); } class User { name = ''; email = ''; ..... folders = []; } class Folder { name = ''; ... projects = []; } class Project { name = ''; ... tasks = []; } class Task { text = ''; .... }копоненты точно так же будут передавать только нужный объект function App({appState}){ return ( <div> <div>{appState.user.name}</div> <div> {appState.user.folders.map(folder=><Folder folder={folder})/>} </div> </div> ) } function Folder({folder}){ return ( <div> <div>{folder.name}</div> <div> {folder.projects.map(project=><Project project={project})/>} </div> </div> ) } function Project({project}){ return ( <div> <div>{project.name}</div> <div> {project.tasks.map(task=><Task task={task})/>} </div> </div> ) } function Task({task}){ return ( <div> <div>{task.text}</div> </div> ) }никакого отличия от мобикса разве что компоненты не нужно врапить в @observer декоратор единственное отличие это только при измении свойства или добавления/удаления из массива нужно вызвать дополнительную функцию update которая будет делать перерендер всего приложения import {update} from './utils'; .... onCommentEditSaveButton = (e)=>{ this.props.comment.text = e.target.value; update(); } .... //util.js export function update(){ ReactDOM.render(<App/>, rootEl) }и получем точно такую же работу с состоянием как в мобиксе только без мобикса. Какие тут могут быть проблемы с дебагом или поддержкой?

ERROR: S client not available

в том что мобх не удобно дебажить ?

как и это самописное

…

вообще не оч понимаю к чему это все

в том что мобх не удобно дебажить ?

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

Я говорил про наше самописное решение которое в нашем проекте

и если продолжать писать в таком духе это выйдет редукс

только хуже

Я говорил про наше самописное решение которое в нашем проекте

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

У нас вышло что-то типа мобх

с глобальным методом апдейт пропс

который по какому-то елементу апдейтит

ну там долгая история

Блин, ну что значит дебажить и поддерживать - все точно такое же как с мобиксом но только без декораторов и мобикса, вот из примера выше - состояние точно такое же const AppState = new class { width; height; ..... user = new User(); } class User { name = ''; email = ''; ..... folders = []; } class Folder { name = ''; ... projects = []; } class Project { name = ''; ... tasks = []; } class Task { text = ''; .... }копоненты точно так же будут передавать только нужный объект function App({appState}){ return ( <div> <div>{appState.user.name}</div> <div> {appState.user.folders.map(folder=><Folder folder={folder})/>} </div> </div> ) } function Folder({folder}){ return ( <div> <div>{folder.name}</div> <div> {folder.projects.map(project=><Project project={project})/>} </div> </div> ) } function Project({project}){ return ( <div> <div>{project.name}</div> <div> {project.tasks.map(task=><Task task={task})/>} </div> </div> ) } function Task({task}){ return ( <div> <div>{task.text}</div> </div> ) }никакого отличия от мобикса разве что компоненты не нужно врапить в @observer декоратор единственное отличие это только при измении свойства или добавления/удаления из массива нужно вызвать дополнительную функцию update которая будет делать перерендер всего приложения import {update} from './utils'; .... onCommentEditSaveButton = (e)=>{ this.props.comment.text = e.target.value; update(); } .... //util.js export function update(){ ReactDOM.render(<App/>, rootEl) }и получем точно такую же работу с состоянием как в мобиксе только без мобикса. Какие тут могут быть проблемы с дебагом или поддержкой?

можно завести декоратор для сеттеров и методов @action, который будет вызывать update тогда чуть красивее получится

можно завести декоратор для сеттеров и методов @action, который будет вызывать update тогда чуть красивее получится

@action не работает с асихронностью, наример мы в приложении сделали setTimeout, из метода вышли, @action вызовет update(), а когда отработает таймаут апдейт уже вызывать некому

@action не работает с асихронностью, наример мы в приложении сделали setTimeout, из метода вышли, @action вызовет update(), а когда отработает таймаут апдейт уже вызывать некому

сработает, если правильно всё написать и использовать волшебные Promise

а хотя

стоп

я погорячился

хотя

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

гайз, что означает термин middleware?

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

гайз, что означает термин middleware?

https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D1%83%D1%8E%D1%89%D0%B5%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B5_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D0%B5

https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D1%8F%D0%B7%D1%83%D1%8E%D1%89%D0%B5%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B5_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D0%B5

ок - спасибо! )

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

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

если папка в корне то просто node_modules

не в корне

в этом и проблема

слэш забыл значит

все файлы (и гитигнор) в /front