Я хотел бы понять, когда уместно использовать промежуточное программное обеспечение redux вместо эпос, наблюдаемый за редукцией (и наоборот).
Из документации промежуточного программного обеспечения redux
Он обеспечивает стороннюю точку расширения между отправкой действия и моментом его достижения редуктором. Люди используют промежуточное ПО Redux для ведения журналов, отчетов о сбоях, взаимодействия с асинхронным API, маршрутизации и многого другого.
Из документации, наблюдаемой за сокращениями.
Хотя вы чаще всего производите действия в ответ на какое-то действие, которое вы получили, на самом деле это не является обязательным требованием! Как только вы окажетесь внутри своего Epic, используйте любые наблюдаемые шаблоны, которые вы хотите, при условии, что все, что выводится из последнего возвращенного потока, является действием.
Я понимаю, что действие в промежуточном программном обеспечении redux может или не может поразить редуктор, и если это произойдет, оно может или не может привести к изменению состояния. В эпосе вы можете произвести новое действие, которое может или не может поразить редьюсер или привести к изменению состояния.
Похоже, что оба могут использоваться для включения побочных эффектов, поэтому разница между ними становится для меня немного размытой.
Вопрос. Является ли основа FRP единственным, что отличает их друг от друга, или есть определенные события в жизненном цикле приложения, которые лучше справляются с классическим промежуточным программным обеспечением или эпическим?
