ага, только написать обертку, чтобы коннектить компоненты или даже можно хок! экшены вынести в файлик, жаль ток асинхронных нет из коробки, но не беда, накостылим погодите-ка... где то я это уже видел, только оно нормально работало, и не лагало...

Я про самый тупой варик, useReducer/useContext без абстракций дальнейших.

А есть польза от реакт дев консоли? Что то не видал что бы ее в курсах использовали.

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

Когда части приложения не связаны

когда части приложения не связаны предпочтительнее юзать useReducer + useContext, вместо стейт менеджера?

когда части приложения не связаны предпочтительнее юзать useReducer + useContext, вместо стейт менеджера?

когда части приложения не связаны предпочтительнее юзать useReducer + useContext, вместо стейт менеджера?

Не ререндер. А анмаунт и маунт заново

С ридаксом ты все связываешь. Кто тебе сказал что контекст плохо и не юзабельно?

Иметь в объекте поле с хешем, которое обновлять вместе с изменением объекта и ссылку на этот хеш кинуть в key компонента App

С ридаксом ты все связываешь. Кто тебе сказал что контекст плохо и не юзабельно?

Ни то, ни другое

https://gist.github.com/XaveScor/99431c573b53b8a0c41fb3b5fec522bc

Лол. Реакт учи. И сделай демку и ключи меняй

Вообще не понятно что хотели донести. У нас все модули не зависимы и стейт в контексте. Нету проблем кроме пирамиды

ничто не мешает тебе юзать разные области стора, считай они будут независимы

Ну вообще да. Даже ридакс можно разбить. Но тут ты не получишь стейт из другого контекста

ага, и ререндер всего дерева на любой апдейт провайдера всего то 🤷🏻‍♂️

Вообще не понятно что хотели донести. У нас все модули не зависимы и стейт в контексте. Нету проблем кроме пирамиды

Ты точно прочитал всю ветку?

Ну, у тебя все стейты уйдёт в корни модулей. Суть не меняется.

Я уточнил что при смене ключа будет не то поведение как написал автор сообщения

Так в чем проблема? Для вас это плохая производительность? Не умение разбить на модули? Или большая пирамида из контекста?

Проблема в том, что ты создаёшь свой стейт менеджер, который на 99.(9)% будет хуже, чем существующие решения на рынке.

Нет. Это реакта решение. Не моё

Иначе зачем нам setState вообще, сидели бы как в vue реактивничали

Реакт даёт тебе инструмент. Далее человек им распоряжается или нормально, или строит костыли.

Проблема в том, что ты создаёшь свой стейт менеджер, который на 99.(9)% будет хуже, чем существующие решения на рынке.

Не понятно про кей и сетстейт. Изменишь кей у апп и все вниз размаунтится и пересоздастся

Этот нет. Потому что не тригернуи

Когда контекст к костылю приравняли? Если нормально делать и выглядит нормально и работает. Для меня минус то что все привязано к реакт и из вне не заюзать. Нужно помнить порядок контекстов

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

К примеру, когда подобный issue появился https://github.com/facebook/react/issues/13739. Контекст хорош для прокидывания статики, но никак не динамики.

В контекстах у нас туча Сервисы для модулей Их стейт. Лагов нету. Все норм

Лагов нет где? На core i7 9990k и на последних айфонах?

К примеру, когда подобный issue появился https://github.com/facebook/react/issues/13739. Контекст хорош для прокидывания статики, но никак не динамики.

Кто тебе сказал? Ты не знаешь как работает контекст?

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

В ридаксе так же

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

Это ререндер не в реальный дом плюс реат проверяет равенство пропосов

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

Если они консюмеры контекста и контекст изменился - значит, и надо было вызвать их перерендер, не?

при том, что даже нет поинта о том, где бы это было полезно (потому что его и нет) (особенно с приходом эффектора в наш мир)

при том, что даже нет поинта о том, где бы это было полезно (потому что его и нет) (особенно с приходом эффектора в наш мир)

Простите, что замутил такой холивар своим тупым вопросом 😂 Мне правда просто интересно было, почему для простейшего Spa с 2-3 страничками сайта нахерачил целый редакс, если там можно было обойтись тупо объектиком с парой изменяемых параметров. 😊

вы про еффорт написали, а что он такого грандиозного изменил, подскажите 😊

Нельзя доказать отсутствие необходимости в СМ, сначала нужно доказать необходимость СМ. Если где-то можно обойтись контекстом и всё ок - то зачем тащить СМ?

аа, ну это конечно меняет ситуацию (нет)

Шо опять про эфекторы

Напиши тесты и докажи не нужность контекста. А пока это такое

целый редакс - это около ста строк кода

вы про еффорт написали, а что он такого грандиозного изменил, подскажите 😊

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

эффектор только) меньше бойлерплейта, удобнее апи, легче на старте его понять, хороший DX

Применимый, потому что если у меня встала задача из данных дом строить и эффективно его обновлять - я пошёл и взял реакт, он решает этот вопрос. Если есть задача пошарить стейт - я взял и пошарил стандартным механизмом. До тех пор, пока для конкретного случая этого достаточно - все дополнительные обвесы не нужны, а ты почему-то исходишь из концепции, в которой редакс - это такое что-то необходимое обязательно и по умолчанию. Странно.

круто! а что такое dx?)

Developer eXpirience (удобство дял разработчика в общем, типы, автокомплиты, fluent api, ...)

Ааа, странно что не DE 😁

ну в транскрипции начала слов одинаковые же) икспириенс ди икс ю икс

Применимый, потому что если у меня встала задача из данных дом строить и эффективно его обновлять - я пошёл и взял реакт, он решает этот вопрос. Если есть задача пошарить стейт - я взял и пошарил стандартным механизмом. До тех пор, пока для конкретного случая этого достаточно - все дополнительные обвесы не нужны, а ты почему-то исходишь из концепции, в которой редакс - это такое что-то необходимое обязательно и по умолчанию. Странно.

У тебя есть фундаментальная ошибка в рассуждениях: ты считаешь, что все механизмы реакта несут добро. Это не так. К примеру, внутренних стейт. Это самое главное зло в реакте. Из-за чего компоненты начинают жить своей неотслеживаемой жизнью, что усложняет переиспользуемость и тестирование.