Где мне хранить локальное состояние промежуточного программного обеспечения redux?

Я использую Redux для управления логикой музыкального плеера. Когда он что-то воспроизводит и внезапно выходит из строя, я хочу иметь возможность перехватить это действие и заставить проигрыватель снова запуститься, но только n раз, так как я не хочу продолжать автоматически повторять попытки бесконечно, если проблему нельзя устранить.

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

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

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

Garrett Motzner 10.08.2018 17:41

Хорошее практическое правило: если я сохраню состояние редукции, а затем перезагружу его, будет ли мое промежуточное ПО (со свежим внутренним состоянием) работать точно так же, как если бы этого не произошло? Если вы можете это сделать, тогда имеет смысл сохранить это внутреннее состояние. В противном случае, вероятно, это состояние приложения.

Garrett Motzner 10.08.2018 17:45
2
2
211
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

На мой взгляд (и основываясь на ограниченной информации о вашем конкретном проекте):

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

Почему?

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

  • Do other parts of the application care about this data?
  • Do you need to be able to create further derived data based on this original data?
  • Is the same data being used to drive multiple components?
  • Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
  • Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
  • Do you want to keep this data consistent while hot-reloading UI components (which may lose their internal state when swapped)?

Как сказал Дан Абрамов:

The way I classify it is when ever state needs to be shared by multiple components or multiple pages and we need to persist some data over route changes, all that data should go inside the redux store.

Вы можете сопоставить эту идею от компонентов к промежуточному программному обеспечению, перефразируя «… Сохранить некоторые данные при изменении маршрута…» на «… Сохранить некоторые данные за [вставьте здесь соответствующую границу]…», например, закрыв и перезапустив приложение.

  1. totalRetries, похоже, не отражает значимого состояния приложения. Это связано с некоторыми «закулисными» операциями ввода-вывода, которые не сохраняются при закрытии приложения или передаче состояния приложения с помощью отладчика. Кто-то может даже возразить, что вы не должна открываете его другим компонентам через состояние редукции, чтобы они не полагались (потенциально меняя) внутреннюю работу вашего промежуточного программного обеспечения.

  2. редукс-сага и т. д. Позволяют нам писать этот тип функциональности очень аккуратным и тестируемым способом без «открытых проводов» в состоянии приложения или пространстве имен модуля. Вы можете использовать сагу для инкапсуляции всего вашего поведения при "воспроизведении звука".

  3. Экспорт редуктора и последующий доступ к его разделенному «общедоступному» состоянию из промежуточного программного обеспечения вносит немало ненужных сложностей.

  4. Если вы хотеть выставляете totalRetries и n другим компонентам, вы можете сделать это с помощью действия, такого как PLAY_AUDIO_RETRY, с действием, содержащим обе переменные в своей полезной нагрузке.

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

Daniel 01.09.2019 22:59

У меня есть аналогичная проблема / вопрос, который я, кажется, не могу понять, но написание этого ответа помогло мне намного ближе! Так что спасибо, что задали вопрос.

jchook 02.09.2019 18:15

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

Daniel 02.09.2019 22:02

Честно говоря, мне труднее всего придумать, какой вопрос задать.

jchook 03.09.2019 00:14

Другие вопросы по теме