Субъективное непопулярное мнение: сам факт наличия лекций, которые сравнивают Context API (который не предназначен для управления реактивным состоянием) cо state manager'ами только путает людей еще больше. Context API и библиотеки управления состоянием решают две совершенно разные задачи. Context API решает задачу представления доступа к "X", игнорируя глубину вложенности элемента(aka внедрение зависимостей, поскольку мы вместо того, чтобы прокидывать этот "аргумент" явно, берем его из некоего контейнера, который спрятан внутри React). Библиотеки управления состоянием же помогают хранить состояние и реагировать на его изменение. Перекладывая на термины Angular(может кому-то будет понятнее): Context'ы - это InjectionToken'ы, которые помогают внедрять сервисы в конструкторы. Поэтому у Context API и нет конфликта с Redux'ом, react-redux пользуется механизмом внедрения зависимостей react'а, чтобы получить доступ к хранилищу из любой точки приложения, а как ты далее будешь реагировать на изменения этого хранилища - это совершенно другой вопрос. Поэтому ответ на вопрос "Почему из коробки нет `useSelector`'а?" должен быть следующим: Context API не решает задачу хранения реактивных данных, и, соответственно, не решает задачу оптимизации ре-рендеров компонентов тоже. В общем и целом правило "Если ты складываешь результат работы `useState` (или его производные с помощью `useMemo`) как `value` в контекст, то, скорее всего, ты что-то делаешь не так" работает великолепно. Храните реактивное состояние в state manager'ах, а Context API используйте для внедрения зависимостей и будет вам счастье.
Спасибо за интересный доклад! Проблему с rerender многие библиотеки решают при помощи Proxy. Не могли бы вы в одном из следующих видео затронуть архитектуру построения и общения mobx store через контекст, так как у них ссылка одинаковая проблем не будет, но раз у вас есть подобный опыт было очень интересно его послушать.
не нужно решать проблемы context API никакими пакетами. Просто не используете его не по назначению. Context отлично подходит для передачи не изменяемых(или редко изменяемых) даных. Для всего остального он не подходит А кейс когда мы импортировали переменную userActions вместо засыввания их в контекст мы вообще скрестили ежа с ужом. Попробуйте теперь заиметь два провайдера такого "контекста" в дереве и вас ждут интересные открытия. Так же распространное заблудение "redux прокидывается данные через контектс". Это не правда. Редакс(а точнее react-redux) не прокидывает данные через контектс. Он прокидывает стор, не данные. Это принципиальная разница. Стор у нас не изменяемый на протежении всей сессии работы с приложением, в то время как данные - изменыемы. А почему противопставили единый источник истины и мультисторовые решения вообще не понятно. Они никак друг другу не противоречат
Столкнулся также с неким неудобством в typescript, когда надо типизировать контекст при его создании (при установке дефолтного значения). С самими сущностями можно определиться, а вот сеттеры к ним, которые используют сеттеры useState в компоненте провайдера, можно определить только после вызова useState в этом компоненте. И приходится эти сеттеры делать опциональными при описании типа контеста. И потом, при вызове в дереве компонентов либо делать проверку на undefined, либо использовать "!". В принципе, наверное, создание контекста можно затащить в компонент провайдера и заюзать для этого ref, но тогда его нельзя экспортировать, и надо объявлять наверху переменную для него неинициализированную, в общем, выглядит это не очень.
Полезное видео для того, чтобы понять, как отказ от контроллеров, ViewModel и DomainEntity в конечном итоге приводит ко множеству проблем и костылей, когда пытаешься управлять состоянием и рендерингом. По сути использование нескольких контекст-провайдеров или сторов - это использование слабовыраженных сущностей предметной области, которые и должны хранить и состояние, и функционал, и быть цельными и изолированными от окружающего мира. Вместо этого мы наблюдаем расчленёнку, где в сторах оказывается состояние DomainEntity, а функционал DomainEntity где-то разбросан по ui-компонентам или экшенам, делая код запутанным и перегружая ui-слой, куда начинает протекать бизнес-логика. Если и делать кастомное управление состоянием, то не на основе контекста, а на базе mobX. MobX - не идеален, но задаёт правильный вектор.
@@it-sin9k Блин, походу мое сообщение с линком на кодсендбокс удалилось, хотел показать тебе как это работает в коде :( Раз уж тут как-то странно со ссылками, загугли пожалуйста Specifying a fallback default value in React Context, цитата: > If React can’t find any providers of that particular context in the parent tree, the context value returned by useContext() will be equal to the default value that you specified when you created that context Изначальное сообщение не видел так что все норм)
Спасибо за доклад, освежил память по context. Ты сказал, что в последнее время не использовал context, а что насчет steppers ( форма с шагами или подобные карусели ), когда нету целесообразности выносить это в store ( нет разницы, mobx или redux ), но в тоже время нужно шарить данные между шагами? Что ты используешь в той структуре?
Всё классно, респект. Но тема эффективного использования не раскрыта, к сожалению. Сделал свой стейт менеджер, который прокидывается через контекст. Причем в нем можно менять состояние "напрямую", условно говоря. Геттеры, сеттеры кто-то юзает...?)) В общем, если интересно, могу скинуть реализацию. Кода очь мало, а использование максимально простое.
Я решил придумать костыль! И это весь реакт - такой! Костыль придумали, расхайпились. А потом полезли грабли и новые костыли, что подпереть костыли на костылях. Про редакс вообще молчу! Дичь несусветная. И приходится с этим ГЭ периодически работать.
А если еще приправить все это тайпскриптом, и проект развивается пару лет. Ой, мама! Какой бардак там будет! И это все проекты на реакт такие. Без исключения.
Контекст Провайдер это тупо scope компонента. Это обеспечивает изоляцию логики-состояния, никто вне скопа, не полезет своими грязными рученками в эти данные.
![[доклад] Подробно о React Reconciliation, или Как React добился 60 fps](http://i.ytimg.com/vi/NPXJnKytER4/mqdefault.jpg)
![[доклад] Подробно о React Reconciliation, или Как React добился 60 fps](/img/tr.png)
Очень интересный доклад, зразу же лайк!И личная просьба выпускай больше видео о React, уж очень качественно
Спасибо!
ВОУ!!!!! Вот на такие доклады - ходил и ходил бы!!! Лайк, Спасибо !
Спасибо!
Субъективное непопулярное мнение: сам факт наличия лекций, которые сравнивают Context API (который не предназначен для управления реактивным состоянием) cо state manager'ами только путает людей еще больше.
Context API и библиотеки управления состоянием решают две совершенно разные задачи. Context API решает задачу представления доступа к "X", игнорируя глубину вложенности элемента(aka внедрение зависимостей, поскольку мы вместо того, чтобы прокидывать этот "аргумент" явно, берем его из некоего контейнера, который спрятан внутри React). Библиотеки управления состоянием же помогают хранить состояние и реагировать на его изменение.
Перекладывая на термины Angular(может кому-то будет понятнее): Context'ы - это InjectionToken'ы, которые помогают внедрять сервисы в конструкторы.
Поэтому у Context API и нет конфликта с Redux'ом, react-redux пользуется механизмом внедрения зависимостей react'а, чтобы получить доступ к хранилищу из любой точки приложения, а как ты далее будешь реагировать на изменения этого хранилища - это совершенно другой вопрос. Поэтому ответ на вопрос "Почему из коробки нет `useSelector`'а?" должен быть следующим: Context API не решает задачу хранения реактивных данных, и, соответственно, не решает задачу оптимизации ре-рендеров компонентов тоже.
В общем и целом правило "Если ты складываешь результат работы `useState` (или его производные с помощью `useMemo`) как `value` в контекст, то, скорее всего, ты что-то делаешь не так" работает великолепно. Храните реактивное состояние в state manager'ах, а Context API используйте для внедрения зависимостей и будет вам счастье.
Спасибо за интересный доклад! Проблему с rerender многие библиотеки решают при помощи Proxy. Не могли бы вы в одном из следующих видео затронуть архитектуру построения и общения mobx store через контекст, так как у них ссылка одинаковая проблем не будет, но раз у вас есть подобный опыт было очень интересно его послушать.
Благодарю за доклад, удивил)
Надеюсь в хорошем плане удивил)
Респект парням, АЙ Синяк разрывной персонаж, очень крутой! Таких больше нет!!! настолько доходчиво объясняет.
Спасибо!
Отличный доклад!
Писали писали без redux с контекстом и в итоге получился Redux..
Спасибо за доклад, очень интересно! Keep doing what you doing!
Спасибо большое! Очень интересно слушать, а самое главное все понятно!
Спасибо! Я очень старался)
Очень круто! Классно! Теперь я знаю больше! Спасибо!) Попутного тебе ветра, добрый человек) и организаторам спасибо)
Спасибо!
Как всегда Отлично) ждем примеров про мобыху🙆
не нужно решать проблемы context API никакими пакетами. Просто не используете его не по назначению. Context отлично подходит для передачи не изменяемых(или редко изменяемых) даных. Для всего остального он не подходит
А кейс когда мы импортировали переменную userActions вместо засыввания их в контекст мы вообще скрестили ежа с ужом. Попробуйте теперь заиметь два провайдера такого "контекста" в дереве и вас ждут интересные открытия.
Так же распространное заблудение "redux прокидывается данные через контектс". Это не правда. Редакс(а точнее react-redux) не прокидывает данные через контектс. Он прокидывает стор, не данные. Это принципиальная разница. Стор у нас не изменяемый на протежении всей сессии работы с приложением, в то время как данные - изменыемы.
А почему противопставили единый источник истины и мультисторовые решения вообще не понятно. Они никак друг другу не противоречат
А если данные часто изменямые (инпут к примеру), то как хранить эти данные глобально если нужен к нему доступ из нескольких других компонентов?
Спасибо большое, очень помогает освежить знания)
В случае с toolkit-ом не вижу смысла useReducer-а. Создаём ещё один slice и все.
Крутой доклад ! Спасибо !
Спасибо за доклад
Столкнулся также с неким неудобством в typescript, когда надо типизировать контекст при его создании (при установке дефолтного значения). С самими сущностями можно определиться, а вот сеттеры к ним, которые используют сеттеры useState в компоненте провайдера, можно определить только после вызова useState в этом компоненте. И приходится эти сеттеры делать опциональными при описании типа контеста. И потом, при вызове в дереве компонентов либо делать проверку на undefined, либо использовать "!". В принципе, наверное, создание контекста можно затащить в компонент провайдера и заюзать для этого ref, но тогда его нельзя экспортировать, и надо объявлять наверху переменную для него неинициализированную, в общем, выглядит это не очень.
Полезное видео для того, чтобы понять, как отказ от контроллеров, ViewModel и DomainEntity в конечном итоге приводит ко множеству проблем и костылей, когда пытаешься управлять состоянием и рендерингом. По сути использование нескольких контекст-провайдеров или сторов - это использование слабовыраженных сущностей предметной области, которые и должны хранить и состояние, и функционал, и быть цельными и изолированными от окружающего мира. Вместо этого мы наблюдаем расчленёнку, где в сторах оказывается состояние DomainEntity, а функционал DomainEntity где-то разбросан по ui-компонентам или экшенам, делая код запутанным и перегружая ui-слой, куда начинает протекать бизнес-логика. Если и делать кастомное управление состоянием, то не на основе контекста, а на базе mobX. MobX - не идеален, но задаёт правильный вектор.
согласен) для разбиения данных на разные сущности, я бы тоже либу юзал, а не context)
Сначала стоит лайкнуть, потом посмотреть. А то некст ролика ждать дольше придется
доклад отличный, спасибо!
Вот это подгон, дружище!
лайк твоему братану)
38:38 - правильно ли я понял что здесь точнее будет не undefined а defaultValue которое мы указали в createContext()?
Отредактировал сообщение) пересмотрел ролик) По идее там будет undefined. Ведь эта часть дерева вообще не покрыта контекстом, поэтому ничего не вернет
@@it-sin9k Блин, походу мое сообщение с линком на кодсендбокс удалилось, хотел показать тебе как это работает в коде :( Раз уж тут как-то странно со ссылками, загугли пожалуйста Specifying a fallback default value in React Context, цитата:
> If React can’t find any providers of that particular context in the parent tree, the context value returned by useContext() will be equal to the default value that you specified when you created that context
Изначальное сообщение не видел так что все норм)
Я часто разбираю х... имходники реакта. Так точно мою работу ещё н кто не описывал 😂
Спасибо за доклад, освежил память по context. Ты сказал, что в последнее время не использовал context, а что насчет steppers ( форма с шагами или подобные карусели ), когда нету целесообразности выносить это в store ( нет разницы, mobx или redux ), но в тоже время нужно шарить данные между шагами? Что ты используешь в той структуре?
по разному бывает, что то в роутере храню (там етсь state), что то в sessionStorage. Все по ситуации
Держался молодцом!
Спасибо!) во второй половине уже чувствовал себя по свободней))
класс!
Кайф!
гуд
Приблизительно 3 года без Redux и уже третий проект на Context + GraphQL.
Сильно!
На сколько большой проект ? Какие проблемы всплывали в ходе разработки ?
@@sergeys4732 Вот здесь я задавал такие же вопросы. И в докладе использовал эту информацию: github.com/Sin9k/useContextPlusUseReducer/pull/1
@@it-sin9k данке))
Меня интересует насколько удобно работать с файлами 3000+ строк, или разработчики React их конкатенируют перед тем как положить на github?
думаю, это они так пишут)
кратко заменит ли контекст Редакс - НЕТ, где использовать контекст - NPM пакеты без обид но возможно профи уловили тонкости мне лично немного пользы
Я использую контекст в кастомных филдах для форм.
Всё классно, респект. Но тема эффективного использования не раскрыта, к сожалению. Сделал свой стейт менеджер, который прокидывается через контекст. Причем в нем можно менять состояние "напрямую", условно говоря. Геттеры, сеттеры кто-то юзает...?)) В общем, если интересно, могу скинуть реализацию. Кода очь мало, а использование максимально простое.
Спасибо :)
Можешь поделиться здесь создав пул реквест
github.com/Sin9k/useContextPlusUseReducer/pulls
@@it-sin9k +
Спасибо! А можно ссылку на репозиторий? В описании не нашёл.
Неужели я забыл добавить))
github.com/Sin9k/useContextPlusUseReducer
Такую элементарную вещь мусолить это нужно уметь
Спасибо!
А можно ссылку на презентацию со всеми ссылками уже в ней? )
Привет :) Добавил в описание, ссылку прямо из конференции скачать слайды. Если не работает, напиши пожалуйста, еще куда залью)
Чето синяк совсем не синяк) Где мешкари под глазами, где треники с растянутыми коленками) Я один что ли пью когда кодю 😢
Так перед выступлением привел себя немного в порядок)) а то неудобно как то)
Зачем вы это сделали? Это был секрет и всех это устраивало…
Я решил придумать костыль!
И это весь реакт - такой!
Костыль придумали, расхайпились. А потом полезли грабли и новые костыли, что подпереть костыли на костылях.
Про редакс вообще молчу! Дичь несусветная.
И приходится с этим ГЭ периодически работать.
А если еще приправить все это тайпскриптом, и проект развивается пару лет.
Ой, мама! Какой бардак там будет!
И это все проекты на реакт такие. Без исключения.
это пройдёт
Есть варианты?
Контекст Провайдер это тупо scope компонента.
Это обеспечивает изоляцию логики-состояния, никто вне скопа, не полезет своими грязными рученками в эти данные.
Дизлайкнул. Не понравилось. Я начинающий и тут какое-то бурление показали. Не разделяю оптимизма докладчка. Хрень.
Из всего комментария, понял только, что не понравилось)
@@it-sin9k ) а что дизлайкнул не поняли?
к сожалению, нет. Если подробнее ответите, буду благодарен :)
Крутой доклад!