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

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

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

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

это 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

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

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

Так а зачем тебе 2 инструмента решающих одну и ту же задачу ?

говорю же, я сейчас четко разделяю: в сагах у меня работа с side effects (api, device, и т.п. что не относится к внутреннему состоянию приложения и меняется не из-за ввода пользователя), а где логика изменения состояния приложения

можно убрать thunk и всё на сагах сделать

можно убрать thunk и всё на сагах сделать

не надо так делать

вот, сколько людей, столько мнений

почему?

Потому что можешь делать, как хочешь, все равно работать будет

Если руки прямые. И не будет - если кривые

я выше описал

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

0

а как же это?

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

вот и поговорили

вы сами начали с вопроса "как заблокировать кнопку чтобы приложение не упало от того что ее много раз нажимают"

считаю просто что redux в RN приложении must have поэтому вся дискуссия свелась в этот контекст

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

https://t.me/uxgifs

просто чтоб не быть голословным, если кто не в курсе https://en.wikipedia.org/wiki/Single_source_of_truth

SSOT не имеет отношения к разделению ответственности между стейтом и редуксом

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

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

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

SSOT нарушается, если мы кладем что-то И в стейт, И в редукс

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

воля ваша

это хорошо, когда к internal state компонента можно пробиться извне или оно никому не нужно, но по мере развития приложения и усложнения его логики предпочтительнее хранить всё в redux

предпочтительнее => я предпочитаю и будет классно сказано:)

вот в кассу вам

что предпочтительнее (что предпочитаете)

передать параметры экрану через props.state навигатора или через редакс?)

ну допустим айдишник выбранной записи для детэйлс-экрана?

передать параметры экрану через props.state навигатора или через редакс?)

первое, ибо в этом кейсе проще)

считаю просто что redux в RN приложении must have поэтому вся дискуссия свелась в этот контекст

позволю не согласится 🙂не все на js пишут RN приложения 😉да и в js необязательно

первое, ибо в этом кейсе проще)

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

предпочтительнее => я предпочитаю и будет классно сказано:)

всё в мире относительно

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

позволю не согласится 🙂не все на js пишут RN приложения 😉да и в js необязательно

а на чем еще можно писать RN приложения?

а на чем еще можно писать RN приложения?

я вот на cljs пишу еще