Separating Workflow Orchestration from UI Reactions in Frontend Applications

This story was originally published on HackerNoon at: https://hackernoon.com/separating-workflow-orchestration-from-ui-reactions-in-frontend-applications.
Emit SUCCESS and NAME_REQUIRED, not SHOW_TOAST. The view-model owns the workflow; the screen owns the reaction.
Check more stories related to programming at: https://hackernoon.com/c/programming. You can also check exclusive content about #frontend, #react, #mobx, #architecture, #typescript, #eventbus, #frontend-architecture, #state-management, and more.

This story was written by: @paulmatvienko. Learn more about this writer by checking @paulmatvienko's about page, and for more stories, please visit hackernoon.com.

Front-end architecture becomes harder to maintain when workflow logic and UI reactions are mixed together. States should represent things that exist over time, while events should represent things that happen. Local workflow events provide a boundary between the two: view-models own the workflow and report outcomes such as SUCCESS, ERROR, or NAME_REQUIRED, while the UI decides how to react with navigation, showing modals, or displaying notifications. This pattern is most useful for complex workflows with multiple branches or UI reactions; for simple local interactions, direct calls are usually easier to understand.