Только не нужно предлагать нормализацию - я уже пробовал - это такие неудобства когда вместо того чтобы простись по ссылкам - comment.task.project.folder вся бизнес логика увешана лапшой вытаскивания нужного объекта по его айдишнику из глобального стора

Где и почему?

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

это же бинес-логика - one-to-many и несколько сущностей - у каждого юзера может быть много папок, у каждой папки может быть много проектов, у каждого проекта может быть много тасков и у каждого таска может быть много комментариев. В одном объекте все не хранится - у объекта юзера есть массив ссылок на папки у папки массив ссылок на проекты и т.д, например user = {name: 'вася, folders: [... {title: 'project1', tasks: [... {title: 'task1', comments: [... {text: 'comment1'}]}]} ]}

Почему - потому что эта плохая структура данных для чтения

а у одного проекта не может быть много юзеров?

это же бинес-логика - one-to-many и несколько сущностей - у каждого юзера может быть много папок, у каждой папки может быть много проектов, у каждого проекта может быть много тасков и у каждого таска может быть много комментариев. В одном объекте все не хранится - у объекта юзера есть массив ссылок на папки у папки массив ссылок на проекты и т.д, например user = {name: 'вася, folders: [... {title: 'project1', tasks: [... {title: 'task1', comments: [... {text: 'comment1'}]}]} ]}

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

И еще она подразумевает бесконечное хранение всех состояний

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

C иммутабельностью сложно разработать некоторую бизнес-логику. Вот придумал такой кейс - у объекта юзера есть массив папок у каждой папки массив проектов у каждого проекта массив тасков и у каждого таска массив комментариев. И теперь юзер отредактировал какой-то комментарий - с мутабельностью все просто - берем и меняем на новое значение comment.text = newValue. А как с иммутабельностью? Нужно создать новый объект комментария, создать новый массив комментариев, перекопировать отстальные комментарии, создать новый массив тасков, перекопировать остальные таски, создать новый массив проектов, перекопировть остальные проекты и наконец создать новый массив папок, перекопировать и создать новый объект юзера. Это же медленнее в тысячи раз.

И еще она подразумевает бесконечное хранение всех состояний

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

Хранятся они до тех пор, пока последняя ссылка на них не исчезнет - все как и везде

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

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

есть же https://github.com/paularmstrong/normalizr

Хранятся все состояния, если хранится последнее

Как только пропадут gc их соберёт.

получается же на каждое действие создается новая структура

такой вопрос можно ли вручную вызывать лайфсайкл методы в реакт?

Ну class properties значения в бинде не нуждаются

Просто в жизни используются другие структуры

Просто в жизни используются другие структуры

Можно вообще обойтись только компонентами-функциями)

При лямбдах из дочерних классов такие методы недоступны

Дочерние классы не нужны. Это JS, тут class - просто удобный способ объекты делать, а не основа ООП.

Дочерние классы не нужны. Это JS, тут class - просто удобный способ объекты делать, а не основа ООП.

О, теперь можно снова спросить, нафига все топят за class вместо createClass :))

А как быть с componentDidMount и componentWillGetProps (или как они называются)?

C иммутабельностью сложно разработать некоторую бизнес-логику. Вот придумал такой кейс - у объекта юзера есть массив папок у каждой папки массив проектов у каждого проекта массив тасков и у каждого таска массив комментариев. И теперь юзер отредактировал какой-то комментарий - с мутабельностью все просто - берем и меняем на новое значение comment.text = newValue. А как с иммутабельностью? Нужно создать новый объект комментария, создать новый массив комментариев, перекопировать отстальные комментарии, создать новый массив тасков, перекопировать остальные таски, создать новый массив проектов, перекопировть остальные проекты и наконец создать новый массив папок, перекопировать и создать новый объект юзера. Это же медленнее в тысячи раз.

я же уже видос кидал почему createClass говно )

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

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

а зачем они тебе? )

Данные с сервака получаю при инициализации компонента

Есть lifecycle в recompose. А так же, эти методы чаще всего требуются контейнерам, их можно сделать по старинке

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

не ну под капотом class MyFoo {} трансформится в обычную функцию

экшн должен вызывать HOC

ну на самом деле createClass уже deprecated

т.е для тебя классы менее понятны чем какая то функция в которую что то надо передавать?

А стоп. А задать как ?