PM
Кирилл Спасибович
ну локальный стейт это типа поля редактора, или какие-то галочки от которых меняется отображаемые поля или кнопки
не только, бывают и данные.
Size: a a a
2020 December 22
КС
в каком случае ?
PM
не, глобальный это тот который нужен не только в 1 компоненте и/или его поддереве. либо если это стейт загружаемый 1 раз
КС
ну допустим у нас есть склад, есть место где в принципе создаются товары сущности, а есть где сколько валяется этих сущностей на каждом складе
КС
под местом понимаю типа экрана
PM
если стейт живет в 1 компоненте, то удобнее если life-cycle стейта будет автоматически управляеться LS компонента. иначе менеджмент буде сложным
КС
по которым можно роутером ходить
КС
ну и вот эти редактируемые товары в общем списке ты бы хранил в компоненте-экране который их отображает, или во внешнем js файле ?
PM
Кирилл Спасибович
ну и вот эти редактируемые товары в общем списке ты бы хранил в компоненте-экране который их отображает, или во внешнем js файле ?
если редактируемые товары загружаются 1 раз и дальше с ними можно манипулировать на клиенте, то можно и в сторе. если это постоянно запрашиваемые туда-сюда данные, зависимые от выборок и живущие пока живет компонент их использующий, тогда смысла их пихать в стор почти нет.
PM
разве что отделить UI от данных. но на этот счет тоже уже придумали компоненты-контейнеры
КС
типа вьюпонт ?)
PM
Кирилл Спасибович
типа вьюпонт ?)
viewpoint?
КС
ага
PM
не,это компонент загрузчик. я про концепцию из реакта. когда есть глупые и умные компоненты
PM
умные как правило просто контейнеры с данными, без UI
PM
они там всякие контексты определяют, данные подсасывают и тп
КС
и размазывают данные по компоненту-представлению ?
PM
Кирилл Спасибович
и размазывают данные по компоненту-представлению ?
да, обычно по целому поддереву
PM
через контекст тот же
PM
короче у меня правило простое- как только нужно одни и те же данные/стейт иметь в нескольких местах, особенно если в рамках разных деревьев, то это сразу стор