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

Нет конечно, управлять такими глупыми должен умный... Это само собой ))) Но вот когда по дизайну в одном углу висит пара списков фильтров, а в другом сложный компонент, вид которого зависит от стейта этого списочника... То прокидывать цепочку явно не вариант... И вот тут мысли о событие/подписка прям лезут в голову... Событие изменения выбора списка в "узел", а уже этот сложный компонент подписывается на это событие и ловит его...

Имхо, редакс сильно топорный.

Скорее всего у этих двух сложных компонентов есть общий родитель

React это либа, а не фреймворк.

Имхо, редакс сильно топорный.

с релизом хуков он уже фреймворк имхо

Но и использование контекста для стейта приложения не правильно

Но и использование контекста для стейта приложения не правильно

Тебе хуки архитектуру приложение задают?

почему не правильно? что есть контекс если не глобальный стейт?

хуки задают путь написания кода

Название само за себя говорит "контекст"

я как-то не улавливаю разницу между абстрактным констектом и абстрактным стейтом

Хуки это просто удобный способ композиции взамен рендер пропов и хоков

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

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

В том и дело, стейт приложения хранить не нужно, тупо сообщить в "рупор" о том, что я-компонент сменил свой стейт... А уже те, кому это нужно, услышат... Что-то типа "pub/sub" редиса...

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

Имхо, это плохая практика.

Почему? По мне вполне, причем укладывается в изначальную событийную модель JS... И делает между прочем абсолютно несвязанными компоненты... есть "компонент = источник события изменения своего стейта"... есть другой компонент "далеко" от источника, который подписывается на это событие и от него "зависит", появился еще один компонент, который тоже зависит от источника, тоже подписался и все - никаких рисков для существующих структур и логики...

и эти два компонента вообще не связаны друг с другом и никак не зависят ни о чего, кроме событий от "компонента-источника", и сама суть "из коробки" была бы крайне удачной... вместо "пристроек" просто юзать в компоненте при инициализации сразу типа events.on('источник события', () => { обработка })...

Используй контекст

Как шину обмена данными

Как шину обмена данными

вот это и хочу поизучать, мне на текущий момент нужна именно шина по сути своей =)

Почему он не видит геоджейсон хотя он там есть?

Почему? По мне вполне, причем укладывается в изначальную событийную модель JS... И делает между прочем абсолютно несвязанными компоненты... есть "компонент = источник события изменения своего стейта"... есть другой компонент "далеко" от источника, который подписывается на это событие и от него "зависит", появился еще один компонент, который тоже зависит от источника, тоже подписался и все - никаких рисков для существующих структур и логики...

Посмотри на effector.

напомнило look at my horse my horse is amazing :)

Нет. В данном случае ему нужна event-модель. Этому effector прекрасно удовлетворяет.

Привет всем. Как можно переписать вот такую вот херню?)

1) Почему это херня? 2) Хачем это переписывать?

Стало крашиться приложение)

Стало крашиться приложение)

Ищи причину краша.

Первое предположение, что в p не нужно передавать to... Если вариант на два варианта return посожет - причина краша установлена )

Ищи причину краша.

Так то это тоже нет смысла вкидывать

Посмотри на ответ на это сообщение. И можно сделать вывод есть смысл такое вкидывать или нет.

Ну да... Огромный смысл в сообщении искать причину краша человеку, который УЖЕ ее ищет и спрашивает совет. Извините, гуру, новичка... Ваши вбросы априори непререкаемы...

Только как-то на подобное бесмысленное сообщение был дан ответ, который должен быть дан https://t.me/react_js/749094. Можешь и дальше токсить и отрицать то, что работает на практике) Одно дело, если человек сам дойдёт до ответа, а другое, если его приучить, что в чате любую, даже самую глупую, проблему решат за него.И надо стремиться к первому, а не к чувакам, котоыре даже текст ошибки прочтитать не могут. Ещё претензии?)

А я думал, что чаты существуют, чтобы помогать, а не для того, чтобы просто отшить, дабы "человек сам доходил"... Что вы тогда тут делаете? Спрашивать - так сами добивайтесь решения... Пинать отшивать вопрошающих - равносильно отсутствию. Так зачем вы в этом чате?

А я думал, что чаты существуют, чтобы помогать, а не для того, чтобы просто отшить, дабы "человек сам доходил"... Что вы тогда тут делаете? Спрашивать - так сами добивайтесь решения... Пинать отшивать вопрошающих - равносильно отсутствию. Так зачем вы в этом чате?

По-моему я догнал. Код срабатывает правильно. Эта хрень рендериться динамически. И в какой-то момент проскакивает вместо строки - нулл.

Задать вопросы, которые направят к решению - это отшить?

Офигенное направление "Ищи причину краша"... Верх гениальности )))

Я тебе ещё раз спрашиваю: ты ответ видел на это сообщение? Или ты агришься на то что работает?

Ответа от автора вопроса на это сообщение в чате нет... Могу скрин кинуть в личку...

Условный рендеринг помог спс. Это самописный компонент Tree. Там чилды рендеряться рекурсивно. И как-то проскакивает нулл на Link.

Уточнение чисто для себя. Т.е. в принципе <p> - может принимать свойство to... Но если значение его вкинуть как null , то идет краш?

Это не мой код, поэтому не сразу догнал что к чему. Там в этом компоненте солидная портянка разметки и он решил сделать ход конём и сделать этот WrappedComponent ) А вылезло это боком мне.

Когда рефакторишь, то лучше делать не такие условия, а в принципе пилить отдельный компонент, тогда проблему куда легче локализовать и исправить. Т.е. сделать const MyLink = ({link}) => { if (link) { return <Link to={link} /> } return <p></p> } Тогда и читаемо сразу становится, и если null попадает, то отладить легко.

Не соглашусь. Если компонент используется многократно и для поиска проблемы заменить в каком то одном месте, а источник/причина краша приходит из другого - то мало того, что свой компонент ничего не даст, так еще и может ввести в заблуждение. Можно, грубо говоря, подменить старый компонент своим вариантом реализации - но это просто один из вариантов изменения "оригинала".

вот это и хочу поизучать, мне на текущий момент нужна именно шина по сути своей =)

А как можно сделать компонент с вариативным тегом без упомянутого мною выше способа? )) Чтоб пропсом можно было управлять какой-то тег отрендерить

Ну можно кстати storeon ещё глянуть (200 байт), там есть возможность чисто на события подписаться, аля pub/sub. Но мне он не нравится.

Офигенное направление "Ищи причину краша"... Верх гениальности )))

Спасибо! Надо попробовать

Но, имхо, если нужно что-то серьёзное делать (появится стор), то лучше выбрать что-то из Redux, Reatom, MobX. Также можно на Effector глянуть

Реатом попробовал?