In this chapter, you learned about the action creator functions that Flux applications utilize in order to dispatch actions. Without action creator functions, we'd have to directly interface with the dispatcher in our code, which makes the architecture more difficult to reason about.
We started off by thinking about action naming conventions and the general organization of our action modules. Grouping action creators by feature has implications for modularity as well, especially in how this influences modularity in other areas of the architecture.
Next, we discussed mocking data using action creator functions. Mocking data in Flux applications is easy to do and encouraged. Actions are the only way for data to enter the system, making it easy for us to switch between mocked action data and our production implementations. We wrapped the chapter up with a look at stateful action creators that listen to things such as web socket connections, and a look at parameterized action creators...