просто мне рил интересно, я ж могу ошибаться, мб ваш подход лучше

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

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

а

я походу понял

вы mapStateToProps делаете динамический подброс подстейтов?

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

вы mapStateToProps делаете динамический подброс подстейтов?

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

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

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

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

а мы пользуемся storybook и там не отобразить компоненты с коннектами (ну или я еще не знаю как)

а мы пользуемся storybook и там не отобразить компоненты с коннектами (ну или я еще не знаю как)

а там и не надо компоненты с коннектами отображать))

это application level, а не отдельные компоненты

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

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

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

нуууу ооок)))

можно сделать так чтобы в сторибуке connect был фейковый)

хотя я конечно им не пользуюсь)

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

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

?

ну вон в контексте кнопки

две кнопки - два экшэна

три кнопки - три

если кнопка свой стейт в редаксе хранит

пока логично говоришь ?

а есть какие то другие варианты?

я в таких случаях делаю пропс name="asfasfds"

и фигачу экшоны changeState(name, value) ))

а, ну дык пожалуйста, я тоже так делаю)

язык то динамический, верти как хочешь)

ну это для тех случаев когда кнопку "отжать" могут по результатам запроса в апи)

а если стей дальше компонента не уходит - то setState конечно)

ну у меня setState, гораздо реже, а то по опыту, придет ПМ и скажет "а вот сделай еще чтобы когда кнопка нажата, какая нибудь хрень внизу в самом исчезала"

рефакторинг - экстракт стэйта в редакс))

рефакторинг - экстракт стэйта в редакс))

ну вот мне проще сразу туда засунуть, чтобы не рефакторить))

ПМу по голове постучать еще можно)) чтоб не умничал часто))

ишь ты бунтарь)

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

постучать это так: тук-тук-тук АЛЁ У ВАС ВСЕ ДОМА?

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

Это quality attribute modifiability

Это quality attribute modifiability

какой то жаргон QA ?

какой то жаргон QA ?

Ну почему же)

субъективно)

не, звучит классно и солидно)

с таким перед начальством стыдно не будет))

с таким перед начальством стыдно не будет))

;)

;)

вот буду теперь на стендапах так говорить (когда на самом деле фигней маялся) ?

Главное не сделать сит даун ☺

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

"Я редукс использую только для отправки/фетча" - шта?

для этого надо saga юзать или thunk на худой конец

тк у меня redux-thunk

а что не так?

+ persist

точнее надо выражаться =)

вот и «шта»

тк по сути это редукс же

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

это side effect какой-то

у нее должно быть в props свойство enabled

и уж откуда оно приходит и сколько времени должно быть on/off - не кнопки это дело

поэтому в контексте redux это on/off должно быть в store

все визуальные компоненты должны быть stateless где только можно

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

напротив: дебажить внутренние state десятка компонентов - это ж адок

а сам компонент от этого стейтлесом не перестанет быть

=)

https://www.youtube.com/watch?v=3aKXZh0IgW4

упорство - хорошая вещь, но если уж взяли redux - зачем эти половинчатые решения?

я даже могу привести случай когда ваш подход на 100% завалится

я даже могу привести случай когда ваш подход на 100% завалится

жги!)

например, на экране список, который можно обновить через pull-to-refresh а можно кнопкой Reload в навбаре и если юзер сначала дернет обновление скроллом, а потом нажмет Reload - вызовется один action который уронит приложение (почему-то?)

а если вы в store положите флаг что нельзя reload action вызывать - всё будет ок

и оба компонента: и кнопка, и список - будут знать что не надо вызывать действие

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

На крайняк уж просто проверить через тот же флаг в state что уже грузятся данные const reloadAction = (dispatch, getState) => { if (!getState().substate.isLoading) { fetch... .then(result => dispatch(loadingDone(result))) ... } }

например, на экране список, который можно обновить через pull-to-refresh а можно кнопкой Reload в навбаре и если юзер сначала дернет обновление скроллом, а потом нажмет Reload - вызовется один action который уронит приложение (почему-то?)

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

вот это вообще правильно

а в thunk просто диспатчить сложносоставные actions

а в thunk просто диспатчить сложносоставные actions

это какие экшины ?

состоящие из элементарных actions =)

состоящие из элементарных actions =)

после какого то экшина вызывать еще какие то ?

// Thunk Actions export const onStart = (user: User, item: Item): ThunkAction => (dispatch: Dispatch) => { dispatch(setItemStarted(item, true)) dispatch(onLoadItemPackage(user, item)) }

это можно и в сагах же делать

соответственно setItemStarted и другие - либо совсем простые либо такие же сложные

можно, но я пока решил в сагах именно side effects обрабатывать

хотя там тоже приходится put и прочее делать, что по сути тот же dispatch...

ну такое в общем

хотя там тоже приходится put и прочее делать, что по сути тот же dispatch...

я как раз про это

но там можно делать допустим лишь один put(action...) который как раз уже будет результат от работы с внешним миром передавать в thunk

жесть

зачем все усложнять ?

не мы такие, жизнь такая

как проще?

что-то одно использовать

тут как раз проще пока что получается, я начинал с чистого redux, потом взял redux-thunk, потом дошел до redux-saga

эволюционировал =)

я не отрицаю, что можно что-то одно, но у меня пока так сложилось