The first paragraph (the one below the graphic) is ok, I don't have problems with it.
Dataflow in Flux. There is a big gap between the last paragraph and this one. You just assume that the reader understands now how the different pieces work together.
I would rewrite it a bit. Something along this lines:
"We will see how this flow works through this chapter, but first, let's get an overview.
First we need to see what kind of actions we have in our app. The actions themselves doesn't have any logic, they are just messages that our app use to communicate. Our app have a couple of actions like create or update and since they are all related to notes, we can create a NoteActions.
Then we have our stores, the stores contains the application state and logic. Since we are talking about notes, we can create our NoteStore. A store is a read only class that serves as a single source of truth (insert wikipedia link). The stores will subscribe themselves to the actions they need and they will have the necessary logic to initialize our model and to manage those actions. So if we had a create action, we add the necessary logic to create new notes.
In the views, we subscribe to our stores so we can retrieve our data and display it as needed.
If in our view we edit a note, it will trigger an action and all the stores subscribed to that action will be notified so they can update their state appropriately. After that, the stores will trigger an event so all the views subscribed to that event can be updated with the new changes.
As you see, this is an unidirectional flow. Views triggers actions, actions gets executed in stores and stores notifies the views with the new data.
If you are wondering where the dispatcher comes in. It is the one who connects executed actions with the stores."
Yikes, this took me a couple of hours and lot of rethinking but it is almost good to drop it in as is.
Then I would tune a bit the chapter to have this explanation in mind.
Also when presenting alt, I would say that Alt simplifies this flow by hiding the dispatcher from the end user and hiding other boilerplate like sending events when the data change.
This is an starter issue, I will continue reading and if you decide to merge this, we will see how can we adapt the rest of the chapter.
The first paragraph (the one below the graphic) is ok, I don't have problems with it.
Dataflow in Flux. There is a big gap between the last paragraph and this one. You just assume that the reader understands now how the different pieces work together.
I would rewrite it a bit. Something along this lines:
"We will see how this flow works through this chapter, but first, let's get an overview.
First we need to see what kind of actions we have in our app. The actions themselves doesn't have any logic, they are just messages that our app use to communicate. Our app have a couple of actions like
create
orupdate
and since they are all related to notes, we can create aNoteActions
.Then we have our stores, the stores contains the application state and logic. Since we are talking about notes, we can create our
NoteStore
. A store is a read only class that serves as a single source of truth (insert wikipedia link). The stores will subscribe themselves to the actions they need and they will have the necessary logic to initialize our model and to manage those actions. So if we had acreate
action, we add the necessary logic to create new notes.In the views, we subscribe to our stores so we can retrieve our data and display it as needed.
If in our view we edit a note, it will trigger an action and all the stores subscribed to that action will be notified so they can update their state appropriately. After that, the stores will trigger an event so all the views subscribed to that event can be updated with the new changes.
As you see, this is an unidirectional flow. Views triggers actions, actions gets executed in stores and stores notifies the views with the new data.
If you are wondering where the dispatcher comes in. It is the one who connects executed actions with the stores."
Yikes, this took me a couple of hours and lot of rethinking but it is almost good to drop it in as is.
Then I would tune a bit the chapter to have this explanation in mind.
Also when presenting
alt
, I would say that Alt simplifies this flow by hiding the dispatcher from the end user and hiding other boilerplate like sending events when the data change.This is an starter issue, I will continue reading and if you decide to merge this, we will see how can we adapt the rest of the chapter.