Unidirectional Data Flow

Many of the remaining examples in this book employ a unidirectional data flow pattern. Popularized by Redux in the world of Web app development, adopting a unidirectional data flow can help simplify how different bits of your app work with that data.

While the details will differ somewhat by implementation, the general approach of a unidirectional data flow (UDF) is to minimize the number of places in the app that can change data. In particular, while a user interface may allow the user to change data, the GUI code itself does not change data, but instead works off of a stream of immutable objects as a source of details for what to render in the GUI itself.

In particular, the UDF approach that will be used in most of the remaining book samples will look a bit like this:

In a nutshell:

• When a user does something in the UI, such as click a toolbar button, the UI calls a function on something called “the motor”
• In response to those calls, the motor asks the repository to read, update, or delete some data, using some sort of asynchronous mechanism
• The result of the repository work gets delivered to the motor via that asynchronous mechanism
• The motor emits a “view state” of details that get used by the UI to update what the user sees