MK
сильная замена редаксу с вариативным апи использованием
Size: a a a
2021 March 13
MK
Мне кажеться ясмысл жизни реактеров в поиске стм, и вечной работы с редаксом, но возможно серверные компоненты с суспенсом сделают подвижки в эту сторону
X
ИМХО, из моего опыта, для большинства проектов от redux больше вреда чем пользы. И для большей части проектов global state вообще не нужен.
X
Я до сих пор не понимаю, почему global state считается хорошим тоном
А
ИМХО, из моего опыта, для большинства проектов от redux больше вреда чем пользы. И для большей части проектов global state вообще не нужен.
Кстати да, если есть хоть 2 компонента куда надо засунуть стейт то сразу начинают пихать в редакс.
Во многих моментах обычных пропсов и useContext сполна хватит. Но проблема в том что приложение может расширяться, и вот тут есть риск что придется много кода переписать.
Во многих моментах обычных пропсов и useContext сполна хватит. Но проблема в том что приложение может расширяться, и вот тут есть риск что придется много кода переписать.
VK
Я до сих пор не понимаю, почему global state считается хорошим тоном
Проблема в том, что описывать логику и потоки данных надо явно
Каким образом это делать?
Мне понравилось как Абрамов сказал, что проблема часто в том, что в редакс кладут кеш, а не состояние
Если у вас есть хороший инструмент для работы с кешем - вам скорее всего не понадобится редакс
Но есть другие стм (типа эффектора или мобх)
Они вообще не про глобальный стейт
Каким образом это делать?
Мне понравилось как Абрамов сказал, что проблема часто в том, что в редакс кладут кеш, а не состояние
Если у вас есть хороший инструмент для работы с кешем - вам скорее всего не понадобится редакс
Но есть другие стм (типа эффектора или мобх)
Они вообще не про глобальный стейт
MK
Проблема в том, что описывать логику и потоки данных надо явно
Каким образом это делать?
Мне понравилось как Абрамов сказал, что проблема часто в том, что в редакс кладут кеш, а не состояние
Если у вас есть хороший инструмент для работы с кешем - вам скорее всего не понадобится редакс
Но есть другие стм (типа эффектора или мобх)
Они вообще не про глобальный стейт
Каким образом это делать?
Мне понравилось как Абрамов сказал, что проблема часто в том, что в редакс кладут кеш, а не состояние
Если у вас есть хороший инструмент для работы с кешем - вам скорее всего не понадобится редакс
Но есть другие стм (типа эффектора или мобх)
Они вообще не про глобальный стейт
ну окей у них просто много глобальных микро сторов)
VK
Проблема в том, что описывать логику и потоки данных надо явно
Каким образом это делать?
Мне понравилось как Абрамов сказал, что проблема часто в том, что в редакс кладут кеш, а не состояние
Если у вас есть хороший инструмент для работы с кешем - вам скорее всего не понадобится редакс
Но есть другие стм (типа эффектора или мобх)
Они вообще не про глобальный стейт
Каким образом это делать?
Мне понравилось как Абрамов сказал, что проблема часто в том, что в редакс кладут кеш, а не состояние
Если у вас есть хороший инструмент для работы с кешем - вам скорее всего не понадобится редакс
Но есть другие стм (типа эффектора или мобх)
Они вообще не про глобальный стейт
Они про то, чтобы описывать работу с состоянием реактивно в каком-то одном месте, оперируя с атомарными сторами а реакт использовать просто как рендерилку
X
Проблема в том, что описывать логику и потоки данных надо явно
Каким образом это делать?
Мне понравилось как Абрамов сказал, что проблема часто в том, что в редакс кладут кеш, а не состояние
Если у вас есть хороший инструмент для работы с кешем - вам скорее всего не понадобится редакс
Но есть другие стм (типа эффектора или мобх)
Они вообще не про глобальный стейт
Каким образом это делать?
Мне понравилось как Абрамов сказал, что проблема часто в том, что в редакс кладут кеш, а не состояние
Если у вас есть хороший инструмент для работы с кешем - вам скорее всего не понадобится редакс
Но есть другие стм (типа эффектора или мобх)
Они вообще не про глобальный стейт
"Проблема в том, что описывать логику и потоки данных надо явно"
Можно вот эту мысль развить? Что под "логикой" подразумевается, что под "потоками данных"
Можно вот эту мысль развить? Что под "логикой" подразумевается, что под "потоками данных"
VK
ну окей у них просто много глобальных микро сторов)
Но это уже не "глоьально")
А
А есть у хуков подобие классового context, чтобы не передавать хуки по всему дереву внутрь?
Хуки импортируйте где нужно. Зачем их передавать?
MK
Но это уже не "глоьально")
почему? каждый компоненнт может взять себе стор, как и у редакса каждый компонент может взять часть стора, да оно разное но сють та же
VK
"Проблема в том, что описывать логику и потоки данных надо явно"
Можно вот эту мысль развить? Что под "логикой" подразумевается, что под "потоками данных"
Можно вот эту мысль развить? Что под "логикой" подразумевается, что под "потоками данных"
Любую логику, работу с состоянием
Описывать что и когда может это состояние изменить
Описывать что и когда может это состояние изменить
Р
Кстати да, если есть хоть 2 компонента куда надо засунуть стейт то сразу начинают пихать в редакс.
Во многих моментах обычных пропсов и useContext сполна хватит. Но проблема в том что приложение может расширяться, и вот тут есть риск что придется много кода переписать.
Во многих моментах обычных пропсов и useContext сполна хватит. Но проблема в том что приложение может расширяться, и вот тут есть риск что придется много кода переписать.
Мне один фронтендер из достаточно крупной айти компании говорил, что редакс нужен везде, даже для локального стейта компонента, потому что так легче расширяться
MK
Мне один фронтендер из достаточно крупной айти компании говорил, что редакс нужен везде, даже для локального стейта компонента, потому что так легче расширяться
ну для локального стейта это он погарячился
VK
почему? каждый компоненнт может взять себе стор, как и у редакса каждый компонент может взять часть стора, да оно разное но сють та же
Но каждая конкретная стора - это какая-то одна область ответственности)
Это, грубо говоря, замена для useState, useEffect и т.п.)
Это, грубо говоря, замена для useState, useEffect и т.п.)
VK
Мне один фронтендер из достаточно крупной айти компании говорил, что редакс нужен везде, даже для локального стейта компонента, потому что так легче расширяться
Ну вот редакс для этого не подходит
Атомарные сторы - наоборот)
Атомарные сторы - наоборот)
А
Мне один фронтендер из достаточно крупной айти компании говорил, что редакс нужен везде, даже для локального стейта компонента, потому что так легче расширяться
Если есть уверенность в большом расширении то да, но редакс как я уже сказал начинают пихать везде где стейты используются больше чем в 1 компоненте
MK
Но каждая конкретная стора - это какая-то одна область ответственности)
Это, грубо говоря, замена для useState, useEffect и т.п.)
Это, грубо говоря, замена для useState, useEffect и т.п.)
давай лучше оперирвоать сущностями, вот например сущность юзера, его имя и все такое, этот стор юзера использут несколько компонентов, это получаеться глобальный микростор, у которого есть состояние и методы для работы с ним
VK
давай лучше оперирвоать сущностями, вот например сущность юзера, его имя и все такое, этот стор юзера использут несколько компонентов, это получаеться глобальный микростор, у которого есть состояние и методы для работы с ним
Ну, он "глобальный" в том смысле, что его можно использовать где угодно, но в нем не хранится все состояние приложения, а только то, что связано с конкретной логикой работы с юзером)