К сожалению ни в каких) есть люди которые используют не смотря ни на что context в своих проектах. Но практической нужды в этом нет. Возможно только крайне специфические задачи, для которых еще не написали библиотеку)
@@it-sin9k Я считаю, что было бы зрителю понятнее, если бы ты сказал, что использование контекста в коммерческих проектах не имеет смысла, а контекст нужен только для создания библиотек.
Из моего опыта: 1) Функции логирования в статистику или в обычные логи - очень удобно хранить в контексте, а не в глобальных синглтонах, т.к. можно в местах оборачивания контекстом указывать какие-то дополнительные поля в логирование. Например, хочется, чтобы события шапки сайта помечались полем place=header, для этого оборачиваем шапку в контекст, и внутри него все события будут слаться с таким place. Но важно, чтобы при использовании этих функций логирования, разработчику не пришлось думать, какой там place отправляется, т.к. будет сложно иногда в родителях компонента найти то место, где оборачивается контекст, чтобы глянуть, какие параметры контекст использует в конкретном компоненте. 2) В текущем проекте мы синглтоны прокидываем через контекст, т.к. в ssr на сервере в ноде глобальные объекты шарятся между сессиями разных пользователей, и можно случайно слить какие-то параметры одного пользователя другому. Плюс это упрощает момент, когда корневой апп на странице может использоваться несколько раз. Ну, это наверное и все, в остальных случаев лучше воспользоваться стейт-менеджером. Стоит очень осторожно использовать контексты, важно следить за стабильностью ссылок, которые вы в него передаете. И желательно понимать, что если вы хотите реактивности от контекста, то эта реактивность будет работать на изменение любого поля в объекте, который вы передали в контекст, что будет перерисовывать лишние компоненты (все жду, когда в реакт добавят github.com/reactjs/rfcs/pull/119 чтобы подписываться на конкретные поля в объекте контекста).
Судя по этому видео с названием "лучшие примеры" - чистый контекст используется тогда, когда надо передать "10", "20" и "30" в разные места приложения :)) А если серьёзно, то именно как автор и сказал примерно в видео - для "удобной" "доступности" неких нужных данных "внизу". ОСОБЕННО в больших приложениях, где трудно и/или уже давно нельзя (опасно) рефакторить, где не всегда ваша команда владелец всего кода..... когда есть некий Апп шелл +куча разных модулей, как consumers, каждый с своим зоопарком решений типо redux разных версий ;) Для доступности "внизу" неких разнообразных API, ОСОБЕННО в больших приложениях, когда надо, чтобы оно всё работало "и как год назад" и "как вчера" и "как хочется сейчас" В общем и целом - легко и элегантно решается проблема props drill, что есть отвратительный антипаттерн. (также как и использование redux для этих целей)
Привет. Случайно наткнулся на твой канал и мне очень понравились твои видео. Хочу сказать, что ты большой молодец, качество контента на высоте. Жаль, что пока у тебя не так много подписчиков, но верю, что если будешь и дальше делать такие полезные и качественные видосы, станешь звездой ютуба :D Не сдавайся и успехов!
Привет. Подскажи, пожалуйста, стоит ли использовать редакс для хранения списка статей на одной из страниц большого проекта? Стоит ли это выносить в хранилище, если статьи нужны только на соответствующей странице? Из общих соображений и личного опыта, посоветуй, пожалуйста?
Привет :) Я выношу в Redux данные чаще всего в двух случаях: 1. Данные используются на многих страницах (например текущий пользователь). 2. Когда текущая страница очень нагружена и сильно связана друг с другом, что локально неудобно обрабатывать ее. Например список статей, с кучей фильтров. Если есть фильтры влияющие на выдачу + пагинация + сам список. То проще такое менеджить через Redux, чем как то локально все это пытаться пробрасывать по компонентам
Контекст ещё интересен тем, что его состояние валидно уничтожается автоматически при размаунте провайдера. То есть мы получаем возможность локализовать стейт из коробки, удобным способом. Стейтменеджеры же предлагают глобальное состояние, которое живет всегда и которое нужно очищать руками. Как мне кажется, бОльшая часть состояний в приложении так или иначе должны иметь ограниченное время жизни(например в рамках одного роута). Интересно как локализуют стейт при повсеместном использовании того же редакса и насколько это удобно/неудобно
Полностью согласен! Я тоже за то, чтобы большинство данных уничтожалось с роутами или компонентами. При использовании Redux, приходится делать reset экшены на анмаунт, не очень люблю это делать
Когда нужно очищать глобальное состояние, желательно делать так, чтобы код очистки был написал один раз. Например, чтобы был объект, где в качестве имен полей были бы имена страниц (или роуты), а в качестве значений были ссылка на сторы для этих страниц. Тогда логику очистки стора для любой страницы получится описать в одном месте. Лучше уж потратить немного времени на что-то такое, чем плодить провайдеры.
@@sergeysibara4346 в случае редакса мне кажется проще создать action с именем resetSomething, который присваивает initialState в store. И на unmount вызывать его
@@sergeysibara4346 у меня скорее поинт о том, что может быть стейтменеджеры с глобальными состояниями не лучший инструмент для хранения данных, у которых время жизни ограничено (например одной страницей)? Мы ведь для обычных функций не пытаемся завести переменные где-то в глобальной области, мы локализируем переменные внутри. Почему тогда данные, ограниченные одной страницей, должны храниться в каком-то глобальном контексте и переживать саму страницу. Если стор страницы будет уничтожаться автоматически при выходе со страницы, как в случае с провайдерами, тогда код очистки стора в принципе не нужно будет писать даже один раз
Мы используем чистые контексты в довольно большом проекте, но без использования useReducer. Это не оч удобно, т.к. четко данные не структурированы, надо следить за порядком контекстов, не забывать про useMemo, useCallback, но в целом жить можно) Добавила ПР в код на гите без useReducer.
Спасибо большое за ПР! Я поделился в ПР-е своими мыслями по поводу вашего кода. Кому интересно, вот ссылка на ПР github.com/Sin9k/useContextPlusUseReducer/pull/1
0:54 Так реакт-редакс же тоже использует контекст. Так что редакс же сам по себе не решает проблему с получением данных в нужном компоненте, а просто занимается их хранением, изменением и оповещением. Не хочу показаться душным, но проблему бурления пропсов же решает не редакс или другие стейт менеджеры, а контекст, а они просто ими пользуются. Мне просто кажется неправильным говорить что редакс решает проблему бурления пропсов, а контекст это спосов решить эту проблему "без сторонних библиотек", а у меня сложилось чувство что ты именно это и имел ввиду. Или возможно я где-то неправ?
Да, я понимаю, что Redux использует Context под капотом. Более того, в предыдущем видео, я рассказывал про это и показывал исходники. В данном случае я исходил скорее с точки зрения обычного пользователя инструментов. Когда стоит перед тобой выбор Context абстракцию самому какую-то пилить, или же использовать Redux, который понятный и привычный. В итоге сэкономить время
Спасибо огромное! как продолжить поддержку из России? сейчас youtube пишет: "Спонсорство отменено Поскольку нам не удалось обработать ваш платеж, спонсорство канала АйТи Синяк было отменено. С уважением, команда TH-cam" может можно на boost как-то июо Patreon из России тож недоступен
Спасибо, что настолько открыты поддержать наш канал! Сложно нам (в РБ) понять какие из сервисов работают для России, если вы знаете какой сервис у вас точно работает, сообщите нам, мы заведем там аккаунт. Еще раз спасибо!
Такого не будет происходить, если дочерний jsx не будет создаваться через react.createElement каждый раз при обновлении стейта контекста. То есть можно отделить провайдера в отдельный компонент, в котором будет стейт контекста и который будет рендерить проп children, обёрнутый в context.provider
@@mikesummer670 дизайн отличается сильно, легче переписать полностью вёрстку, ну я ещё использую контекст когда скрываю навбар слева или хедер и футер на тех страницах, где по дизайну они не нужны
Так чистый контекст (не его библиотечное использование) в больших проектах при каких случаях используется?
К сожалению ни в каких) есть люди которые используют не смотря ни на что context в своих проектах. Но практической нужды в этом нет. Возможно только крайне специфические задачи, для которых еще не написали библиотеку)
@@it-sin9k
Я считаю, что было бы зрителю понятнее, если бы ты сказал, что использование контекста в коммерческих проектах не имеет смысла, а контекст нужен только для создания библиотек.
@@FerelUltra я для этого делал отдельное видео: "Эксперимент useReducer + useContext". Но на всякий случай запиню ваш комментарий!
Из моего опыта:
1) Функции логирования в статистику или в обычные логи - очень удобно хранить в контексте, а не в глобальных синглтонах, т.к. можно в местах оборачивания контекстом указывать какие-то дополнительные поля в логирование. Например, хочется, чтобы события шапки сайта помечались полем place=header, для этого оборачиваем шапку в контекст, и внутри него все события будут слаться с таким place. Но важно, чтобы при использовании этих функций логирования, разработчику не пришлось думать, какой там place отправляется, т.к. будет сложно иногда в родителях компонента найти то место, где оборачивается контекст, чтобы глянуть, какие параметры контекст использует в конкретном компоненте.
2) В текущем проекте мы синглтоны прокидываем через контекст, т.к. в ssr на сервере в ноде глобальные объекты шарятся между сессиями разных пользователей, и можно случайно слить какие-то параметры одного пользователя другому. Плюс это упрощает момент, когда корневой апп на странице может использоваться несколько раз.
Ну, это наверное и все, в остальных случаев лучше воспользоваться стейт-менеджером.
Стоит очень осторожно использовать контексты, важно следить за стабильностью ссылок, которые вы в него передаете. И желательно понимать, что если вы хотите реактивности от контекста, то эта реактивность будет работать на изменение любого поля в объекте, который вы передали в контекст, что будет перерисовывать лишние компоненты (все жду, когда в реакт добавят github.com/reactjs/rfcs/pull/119 чтобы подписываться на конкретные поля в объекте контекста).
Судя по этому видео с названием "лучшие примеры" - чистый контекст используется тогда, когда надо передать "10", "20" и "30" в разные места приложения :))
А если серьёзно, то именно как автор и сказал примерно в видео - для "удобной" "доступности" неких нужных данных "внизу".
ОСОБЕННО в больших приложениях, где трудно и/или уже давно нельзя (опасно) рефакторить, где не всегда ваша команда владелец всего кода..... когда есть некий Апп шелл +куча разных модулей, как consumers, каждый с своим зоопарком решений типо redux разных версий ;)
Для доступности "внизу" неких разнообразных API, ОСОБЕННО в больших приложениях, когда надо, чтобы оно всё работало "и как год назад" и "как вчера" и "как хочется сейчас"
В общем и целом - легко и элегантно решается проблема props drill, что есть отвратительный антипаттерн. (также как и использование redux для этих целей)
Большое спасибо, видео очень кстати 👍👍👍
кратко и по делу 👍
Спасибо за отличное видео! недавно подписался на канал - спасибо за труд
Мой коммент к прошлому видео описан в видео!)
ага)
Спасибо!)
Синяк, ты красавчик
Классное видео, как всегда)
Спасибо!)
Топ видео, очень познавательно!
Привет. Случайно наткнулся на твой канал и мне очень понравились твои видео. Хочу сказать, что ты большой молодец, качество контента на высоте. Жаль, что пока у тебя не так много подписчиков, но верю, что если будешь и дальше делать такие полезные и качественные видосы, станешь звездой ютуба :D
Не сдавайся и успехов!
Спасибо! Будем стараться)
Не планируете видео про mobx? Уж очень мало материала о нем...
Есть мысль такая дойти до mobx, тем более что у меня несколько лет опыта на нем. Но только попозже как то :)
Привет.
Подскажи, пожалуйста, стоит ли использовать редакс для хранения списка статей на одной из страниц большого проекта? Стоит ли это выносить в хранилище, если статьи нужны только на соответствующей странице? Из общих соображений и личного опыта, посоветуй, пожалуйста?
Привет :)
Я выношу в Redux данные чаще всего в двух случаях:
1. Данные используются на многих страницах (например текущий пользователь).
2. Когда текущая страница очень нагружена и сильно связана друг с другом, что локально неудобно обрабатывать ее. Например список статей, с кучей фильтров. Если есть фильтры влияющие на выдачу + пагинация + сам список. То проще такое менеджить через Redux, чем как то локально все это пытаться пробрасывать по компонентам
@@it-sin9k , спасибо! Значит я делаю и думаю правильно!)
Контекст ещё интересен тем, что его состояние валидно уничтожается автоматически при размаунте провайдера. То есть мы получаем возможность локализовать стейт из коробки, удобным способом. Стейтменеджеры же предлагают глобальное состояние, которое живет всегда и которое нужно очищать руками. Как мне кажется, бОльшая часть состояний в приложении так или иначе должны иметь ограниченное время жизни(например в рамках одного роута).
Интересно как локализуют стейт при повсеместном использовании того же редакса и насколько это удобно/неудобно
Полностью согласен! Я тоже за то, чтобы большинство данных уничтожалось с роутами или компонентами. При использовании Redux, приходится делать reset экшены на анмаунт, не очень люблю это делать
Когда нужно очищать глобальное состояние, желательно делать так, чтобы код очистки был написал один раз. Например, чтобы был объект, где в качестве имен полей были бы имена страниц (или роуты), а в качестве значений были ссылка на сторы для этих страниц. Тогда логику очистки стора для любой страницы получится описать в одном месте. Лучше уж потратить немного времени на что-то такое, чем плодить провайдеры.
@@sergeysibara4346 в случае редакса мне кажется проще создать action с именем resetSomething, который присваивает initialState в store. И на unmount вызывать его
@@sergeysibara4346 у меня скорее поинт о том, что может быть стейтменеджеры с глобальными состояниями не лучший инструмент для хранения данных, у которых время жизни ограничено (например одной страницей)?
Мы ведь для обычных функций не пытаемся завести переменные где-то в глобальной области, мы локализируем переменные внутри.
Почему тогда данные, ограниченные одной страницей, должны храниться в каком-то глобальном контексте и переживать саму страницу.
Если стор страницы будет уничтожаться автоматически при выходе со страницы, как в случае с провайдерами, тогда код очистки стора в принципе не нужно будет писать даже один раз
@@it-sin9k Спасибо за ответ, да, reset не выглядит удобно)
Мы используем чистые контексты в довольно большом проекте, но без использования useReducer. Это не оч удобно, т.к. четко данные не структурированы, надо следить за порядком контекстов, не забывать про useMemo, useCallback, но в целом жить можно) Добавила ПР в код на гите без useReducer.
Спасибо большое за ПР! Я поделился в ПР-е своими мыслями по поводу вашего кода. Кому интересно, вот ссылка на ПР
github.com/Sin9k/useContextPlusUseReducer/pull/1
я не понял, как это делать разные значения в разных местах приложения из одно контекста. техничечки
0:54 Так реакт-редакс же тоже использует контекст. Так что редакс же сам по себе не решает проблему с получением данных в нужном компоненте, а просто занимается их хранением, изменением и оповещением. Не хочу показаться душным, но проблему бурления пропсов же решает не редакс или другие стейт менеджеры, а контекст, а они просто ими пользуются. Мне просто кажется неправильным говорить что редакс решает проблему бурления пропсов, а контекст это спосов решить эту проблему "без сторонних библиотек", а у меня сложилось чувство что ты именно это и имел ввиду. Или возможно я где-то неправ?
Да, я понимаю, что Redux использует Context под капотом. Более того, в предыдущем видео, я рассказывал про это и показывал исходники. В данном случае я исходил скорее с точки зрения обычного пользователя инструментов. Когда стоит перед тобой выбор Context абстракцию самому какую-то пилить, или же использовать Redux, который понятный и привычный. В итоге сэкономить время
спасибо, но не понятно как использовании контекста запретить рирендер дочерних компонентов
Если компонент использует данные контекста, так и не надо запрещать :)
Спасибо огромное! как продолжить поддержку из России?
сейчас youtube пишет:
"Спонсорство отменено
Поскольку нам не удалось обработать ваш платеж, спонсорство канала АйТи Синяк было отменено.
С уважением,
команда TH-cam"
может можно на boost как-то июо Patreon из России тож недоступен
Спасибо, что настолько открыты поддержать наш канал! Сложно нам (в РБ) понять какие из сервисов работают для России, если вы знаете какой сервис у вас точно работает, сообщите нам, мы заведем там аккаунт. Еще раз спасибо!
У нас хорошая новость! Мы создали аккаунт на boosty! Там нас можно поддержать!
boosty.to/sin9k
Мне казалось что контекст при изменении перерендерит все дочерние компоненты
Такого не будет происходить, если дочерний jsx не будет создаваться через react.createElement каждый раз при обновлении стейта контекста.
То есть можно отделить провайдера в отдельный компонент, в котором будет стейт контекста и который будет рендерить проп children, обёрнутый в context.provider
А теперь давай видео - "Почему стейт менеджеры и контексты в 90% случаев уже не нужны". Я про хуки react-query, swr.
А я использую контекст для мобильной версии сайта
const isMobile = useContext(mobile)
И в компоненте так делаю
return isMobile ? :
И логику 2 раза пишешь для каждого "продукт"?
@@mikesummer670 зачем?) Просто в главной компоненте прописываю логику, а потом пропсами кидаю в каждый нужную инфу
@@deantek А медиазапросы чем не устроили?
Если касательно смысла этого видоса - то контекст изобрели чтоб не прокидывать пропсы)
@@mikesummer670 дизайн отличается сильно, легче переписать полностью вёрстку, ну я ещё использую контекст когда скрываю навбар слева или хедер и футер на тех страницах, где по дизайну они не нужны
@@mikesummer670 ну один прокинутый пропс намного легче, чем логику дублировать два раза)
сча посмотрим
Если ты не лучший, то кто?
Все Дэна Абрамова любят еще)
@@it-sin9k И всё же)
за react-final-form дизлайк ментальный, так как это дерьмище ещё то в сложных структурных проектах, а так видосу лейкоцит