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

слушайте, архитектурный тупик, вот юзаю redux точка

слушайте, архитектурный тупик, вот юзаю redux точка

что удобного вместо redux заюзать советуешь?

что бы решало проблему выше

Нормализация, видимо

что удобного вместо redux заюзать советуешь?

window.store = {}

Нормализация, видимо

а по подробнее?

window.store = {}

слишком толсто)

а по подробнее?

В смысле ты у себя нормализуй. Сделай все плоско и отдельно связи пропиши

window.store = {}

А теперь подпишись на обновления

В смысле ты у себя нормализуй. Сделай все плоско и отдельно связи пропиши

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

window.store = new Proxy

А теперь подпишись на обновления

Эт слишком усложняет жизнь

window.store = new Proxy

не полифилится)

Да даже window есть не всегда ?

Да даже window есть не всегда ?

о, эффектор такую задачу решает?)

window.store = new Proxy

???

о, эффектор такую задачу решает?)

Ну да

Он для такого и задумывался

Да даже window есть не всегда ?

global.store = {}

Все просто и не нужен эффектор (сарказм)

global.store = {}

Нельзя

о, эффектор такую задачу решает?)

ты про сср?)

Там мой стор лежит

?

ты про сср?)

не, про редюсер и фичу, и проблема когда фича в фиче, изолированность ридакса от реакта идет прахом)

Он для такого и задумывался

что то сходу не вьехал в него)

Ух https://habr.com/post/348586/

что то сходу не вьехал в него)

Основные приемы: const addItem = createEvent('name') const list = createStore([]) list.on(addItem, (list, item) => [... list, item]) const lengthMessage = list.map( list => 'length: ' + list.length ) const both = createStoreObject({list, lengthMessage}) both.watch(obj => {console.log(obj.lengthMessage)}) addItem('foo') addItem('bar') // => length: 1 // => length: 2

Каждый createStore — как отдельный редакс-стор, чтобы их можно было вычислять по раздельности createEvent создает action creator, функцию вызывающую обновление всех слушателей, подписанных через .on и .watch

Основные приемы: const addItem = createEvent('name') const list = createStore([]) list.on(addItem, (list, item) => [... list, item]) const lengthMessage = list.map( list => 'length: ' + list.length ) const both = createStoreObject({list, lengthMessage}) both.watch(obj => {console.log(obj.lengthMessage)}) addItem('foo') addItem('bar') // => length: 1 // => length: 2

А почему нельзя навесить обработчик на lengthMessage сразу? ? без both

Чтобы в примере упомянуть createStoreObject)

Естественно можно навешивать сразу, так даже лучше)

Основные приемы: const addItem = createEvent('name') const list = createStore([]) list.on(addItem, (list, item) => [... list, item]) const lengthMessage = list.map( list => 'length: ' + list.length ) const both = createStoreObject({list, lengthMessage}) both.watch(obj => {console.log(obj.lengthMessage)}) addItem('foo') addItem('bar') // => length: 1 // => length: 2

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

Естественно можно навешивать сразу, так даже лучше)

Понял

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

Ага

Ага

типа вот забацал я фичу А, со своим стором, стор объединяю, и в фиче Б пропсами прокидываю данные для стора его стора и стора Б, хмммм, чёта сам запутался)))

или я просто со стора фичи Б могу брать данные для стора вложенный фиче

во вот это уже на правду похоже становится)

Ага

блин классная идея)

Ещё кстати вот так можно import {createComponent} from 'effector-react@next' const LengthMessage = createComponent( lengthMessage, (props, state) => ( <div>{state}</div> )) <LengthMessage />

@ZeroBias ты когда скринкасты пойдешь пилить на egghead.io ?) там вроде все есть mobx,redux не стоит нарушать традиций

Чёрт, по ходу придётся)

И доку!

axios зачем , есть же fetch

axios зачем , есть же fetch

fetch - инструмент, axios - библиотека

Ух https://habr.com/post/348586/

тут еще аж в 2016 чикохуззу топил за глиммер

тут еще аж в 2016 чикохуззу топил за глиммер

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

не представляю))

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

Не будет)

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

Давай на Паскале сразу, че ты.

Давай на Паскале сразу, че ты.

а чего питон классный язык)

Без let/const нормальному человеку невозможно писать

fetch - инструмент, axios - библиотека

Обертка пишется в 50 строк, экзайос весит несколько килобайт

Без let/const нормальному человеку невозможно писать

старое доброе value VALUE)

старое доброе value VALUE)

Линтер подскажет?

Или компилятор

Линтер подскажет?

не понял,

не понял,

Не мутировать VALUE

Не мутировать VALUE

а чего б не подсказал бы?)

а чего б не подсказал бы?)

А если нет линтера?

В жс просто еррор будет

А если нет линтера?

?

а если комп сгорел?)

ERROR: S client not available

const obj = {}

Не ну завязываться на инструмент не стоит

дофига он тебе подскажет

Ты не напишешь obj = lol

let,const сахар в плане типизации

В питоне изи

И ищи потом где мутировал ссылку

Иммутабельность - наше все.

В питоне изи

так же будет линтером, как и в js

ну блин, его еще нет и вероятней появления во фронте мала, а мы тут уже воюем)

И надеюсь что отовсюду уйдет)

Либо лет конст завезут

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

вообще у каждого языка свои плюс, вот к примеру смотри какая красота в R

numbers <- c(1, -1, 3, -2, 0, NaN) positives <- numbers[numbers>0 & !is.nan(numbers)] negatives <- numbers[numbers<0 & !is.nan(numbers)]

векторизация вообще огонь)

my_function <- function(args) { return(args) } my_function(10)

функции, аля js, если только странный символ присваивания отбросить)

my_function <- function(args) { return(args) } my_function(10)

Чет не впечатлён

Зачем писать return, компилятор сам не поймет где он?

let foo = { let bar = 10; bar; }; всё что в блоке последнее — становится return, изи

Реализую плейсхолдер. Есть экшн, оповещающий сагу о необходимости начать загрузку. Сага после загрузки данных диспатчит экшен в редьюсер о успешной загрузки. В каком месте можно дать знать компоненту производящему рендер загруженных данных, что загрузка идёт и надо показать спинер? Можно ли для этого считывать экшен в редьюсере, предназначенный для саги и переключать флажок fetching?

Реализую плейсхолдер. Есть экшн, оповещающий сагу о необходимости начать загрузку. Сага после загрузки данных диспатчит экшен в редьюсер о успешной загрузки. В каком месте можно дать знать компоненту производящему рендер загруженных данных, что загрузка идёт и надо показать спинер? Можно ли для этого считывать экшен в редьюсере, предназначенный для саги и переключать флажок fetching?

В редюсере добавляешь поле isLoading

Реализую плейсхолдер. Есть экшн, оповещающий сагу о необходимости начать загрузку. Сага после загрузки данных диспатчит экшен в редьюсер о успешной загрузки. В каком месте можно дать знать компоненту производящему рендер загруженных данных, что загрузка идёт и надо показать спинер? Можно ли для этого считывать экшен в редьюсере, предназначенный для саги и переключать флажок fetching?

> Есть экшн, оповещающий сагу о необходимости начать загрузку В редьюсере на этот экшен навешиваешь, как выше сказали, isLoading: true, после успешного выполнения или нет isLoading: false

> Есть экшн, оповещающий сагу о необходимости начать загрузку В редьюсере на этот экшен навешиваешь, как выше сказали, isLoading: true, после успешного выполнения или нет isLoading: false

Это я понимаю. Тут вопрос немного в другом. Работая с танками, считывал в редьюсере оба экшена - экшен оповещающий о начале загрузки и экшен, говорящий о том, что данные пришли. Но в сагах, сначала диспачится экшен для саги, а редьюсер начинает работу только, когда данные пришли. ВОПРОС: правильно ли будет обрабатывать экшен type: "FETCHING" в редьюсере, если этот же экшен считывается сагой?

То есть, диспачится экшен type: "FETCHING" и вотчер-сага говорит рабочей саге начать загрузку нужных данных, после этот же экшен type: "FETCHING" доходит до редьюсера и говорит что надо переключить флажок. Это нормально или стоит делать как-то иначе?

Это я понимаю. Тут вопрос немного в другом. Работая с танками, считывал в редьюсере оба экшена - экшен оповещающий о начале загрузки и экшен, говорящий о том, что данные пришли. Но в сагах, сначала диспачится экшен для саги, а редьюсер начинает работу только, когда данные пришли. ВОПРОС: правильно ли будет обрабатывать экшен type: "FETCHING" в редьюсере, если этот же экшен считывается сагой?

почему нет?

Сначала экшен хватает редьюсер, ставит isLoading: true, потом его ловит сага, начинает загружать, потом возвращает резуьтат в редьюсер

Всем добрый день, не подскажите хороший ресурс с которого можно было бы начать обучение React? Пока прохожу курс на freecodecamp.org

react.express

react.express

Большое вам спасибо.