мне тоже кажется, что все эти солиды, di, dip и пр для жс приложений - муторный оверхед

Не, ну на солид гнать, такое.

ну, т.е. некоторые принципы можно соблюдать, но без излишнего усердия :)

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

Ок, в чём проблема? Возьми effector. Будет тебе и безнес логика, и стейт, и view.

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

Или redux + оболочку к нему.

Ок, в чём проблема? Возьми effector. Будет тебе и безнес логика, и стейт, и view.

и возможно ssr, не я согласен, что возможно di излишне

опять же, я привык писать под wpf / uwp / asp core и прочую ернуду, где без этого очень тяжело, поэтому не совсем понимаю, как (и зачем) такое протаскивать в жс

опять же, я привык писать под wpf / uwp / asp core и прочую ернуду, где без этого очень тяжело, поэтому не совсем понимаю, как (и зачем) такое протаскивать в жс

точно так же

di нафиг не нужен в реакт приложении.

Не нужна исключительно их странный подход к этому

Ок, в чём проблема? Возьми effector. Будет тебе и безнес логика, и стейт, и view.

И di ?

И di ?

Ну, не совсем)

точно так же

ну а зачем ?

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

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

Хорошо. А DI зачем?)

ну, вообще, для любителей ООП было бы неплохо (наверное) инжектить какие-то сервисы в какие-то компоненты, но вот хз

во всяком случае, так было бы привычнее

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

кто-то юзает docz.site? чет не работает NODE_PATH для резолвинга

кто-то юзает docz.site? чет не работает NODE_PATH для резолвинга

у них же есть конфиг

у них же есть конфиг

там нет такого поля

сделай issue

а как лучше инициализоровать стейт в реакте ?

в редаксе *

Ну, не совсем)

Я просто слегка с другой стороны подходил к этому Но по факту вот: эффекты — это строго типизированные контейнеры для функций, а эвенты под капотом являются минимально возможной инверсией контроля: const createEvent = () => { const event = data => event.create(data) event.create = () => {'default create func'} return event }

Я просто слегка с другой стороны подходил к этому Но по факту вот: эффекты — это строго типизированные контейнеры для функций, а эвенты под капотом являются минимально возможной инверсией контроля: const createEvent = () => { const event = data => event.create(data) event.create = () => {'default create func'} return event }

Кстати, я не особо смотрел. У тебя контекстнозависимый стор?

Это как?

Это как?

const App = <> <C /> <C /> </> В C используется effector. У них стор будет один или разные?

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

Лучше всех сечёшь фишку)

const App = <> <C /> <C /> </> В C используется effector. У них стор будет один или разные?

А, понял, не, я не хочу контекстную зависимость, лучше локальную

Лучше всех сечёшь фишку)

секу, но как решить проблему глобального стора я хз

А, понял, не, я не хочу контекстную зависимость, лучше локальную

И как жить в таком случае?

Я просто думал над подобием эффектора, но нормального решения контекста не придумал.

Глобальный стор — это локальный стор для директории src

Я просто думал над подобием эффектора, но нормального решения контекста не придумал.

продолжаю думать в этом направлении

Далее можно просто спускаться по дереву features

Я просто думал над подобием эффектора, но нормального решения контекста не придумал.

контекст в идеале ты берёшь из объединения нужных тебе частей стора

контекст в идеале ты берёшь из объединения нужных тебе частей стора

Я хочу иметь независимые части из коробки, а не "костылить с контекстом".

продолжаю думать в этом направлении

И как? Есть подвижки?

И как? Есть подвижки?

небольшие проблема скорее в api чем в имплементации

Я хочу иметь независимые части из коробки, а не "костылить с контекстом".

так ты и имеешь независимые части, а в чём костыль?

так ты и имеешь независимые части, а в чём костыль?

В том, что надо на что-то завязываться.

Я признаю, что вчера мне доказали, что контекстные зависимости имеют право на существование, но я по прежнему считаю это довольно редким и сильно специфичным кейсом

Блин, решение то простое.

Вообще либы не касается.

Всё, эффектор идеален)

Блин, решение то простое.

м?

В том, что надо на что-то завязываться.

создай компонент, создай в нём стор, прокинь контекст

м?

import {createComponentA} from './createComponentA' const A1 = createComponentA() const A2 = createComponentA()

А в А хреначим локальные сторы и всё прекрасно.

Я уверен, что это однозначно не должны быть компоненты

А в А хреначим локальные сторы и всё прекрасно.

с эффектором так не работает

И тогда контекст нафиг не сдался.

с эффектором так не работает

Почему?

Почему?

ивенты и сторы нужно класть в замыкание

Я уверен, что это однозначно не должны быть компоненты

Вот поэтому

Я признаю, что вчера мне доказали, что контекстные зависимости имеют право на существование, но я по прежнему считаю это довольно редким и сильно специфичным кейсом

Но

Ладно, гляну исходники для лучшего понимания.

@artalar можешь скинуть свой sandbox с решением через createStores, createEvents

гайс, а что можно юзать кроме react-dates ?

Всем привет, подскажите как можно в create react app переопределить конфиг вебпака, чтобы убрать hash в именах файлов

Всем привет, подскажите как можно в create react app переопределить конфиг вебпака, чтобы убрать hash в именах файлов

eject

ERROR: S client not available

)

Блин, у нас есть профи cra. Давайте его звать? Что он просто так в чате сидит?

?интересно для чего понадобилось убрать hash O_O

?интересно для чего понадобилось убрать hash O_O

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

Всем привет, подскажите как можно в create react app переопределить конфиг вебпака, чтобы убрать hash в именах файлов

ищи rewire на эту тему

@artalar можешь скинуть свой sandbox с решением через createStores, createEvents

https://codesandbox.io/s/1y6n4r6o57

https://codesandbox.io/s/1y6n4r6o57

спасибо

https://codesandbox.io/s/1y6n4r6o57

@XaveScor

О, кстати можно же это сделать на основе StoreConsumer

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

кто-нито знает, почему при верхнем варианте дропдаун при нажатии на ссылку (LinkContainer) скрывается, но если выделить 3 обведённые строчки в отдельный компонент (MenuItemLink), то уже не скрывается (не рендерится ServiceMenu)

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

Хотелось бы вообще уйти от явного id.

Это бесполезная нагрузка.

Хотелось бы вообще уйти от явного id.

Ну я так и ушёл, так как написав этот код, получаю инверсию зависимостей по желанию во всем остальном коде

Я просто считаю что ооп-di тупо забыл зачем оно всё нужно было

Ну я так и ушёл, так как написав этот код, получаю инверсию зависимостей по желанию во всем остальном коде

Не понял тебя. В примере явно используется id. Я предположил, что создавая стор в замыкании, он получится локально для каждого компонента. Сова сказал, что так работать не будет(хз почему).

А, ну там технические нюансы уже

В итоге выльется, что у нас будут для всех компонентов createAbcComponent функции)

Я уже выше написал, я сомневаюсь что это будут компоненты

Компоненты — это view, а тут что-то типа сервисов получается

Я уже выше написал, я сомневаюсь что это будут компоненты

Ну, куча компонентов в замыкании.

Т.е. вызывая функцию мы получаем какой-то набор компонентов, привязанных к своему стору.

Надо обмозговать.

О, кстати можно же это сделать на основе StoreConsumer

стейт общий - соединение нескольких state part, события - не именовання дичь а ссылочные указатели на часть стейта + новое значение, трансформы/редьюсеры/морфы подключаемые - per state part, в итоге - изменение отправляется в рут, оттуда спускается вниз по подключенным трансформам/редьюсерам/морфам и получаем итоговый стейт ограничения - 1. Внутренний трансформ/редьюсер/морф не знает о внешнем стейте и не может его менять, внешний трансформ/редьюсер/морф знает всё о внутреннем стейте и может его менять 2. трансформ/редьюсер/морф - чистая функция 3. каждый state part может отдать только свой стейт, селектит от общего

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

стейт общий - соединение нескольких state part, события - не именовання дичь а ссылочные указатели на часть стейта + новое значение, трансформы/редьюсеры/морфы подключаемые - per state part, в итоге - изменение отправляется в рут, оттуда спускается вниз по подключенным трансформам/редьюсерам/морфам и получаем итоговый стейт ограничения - 1. Внутренний трансформ/редьюсер/морф не знает о внешнем стейте и не может его менять, внешний трансформ/редьюсер/морф знает всё о внутреннем стейте и может его менять 2. трансформ/редьюсер/морф - чистая функция 3. каждый state part может отдать только свой стейт, селектит от общего

Лучше идти снизу вверх, от частного к общему

Можно вопрос из зала: нафига общий стейт?

Индуктивно

Для большинства задач он нафиг не сдался.