Improve: demo and README

[vadymmarkov]

@zenangst @RamonGilabert @onmyway133
Now we have 2 demo projects (simple and more advanced) + 1 interactive playground. More about them in README, which is almost completed as well.

[zenangst]

I loved reading this README, I just found some nit-picking things that we might want to change before we merge this PR. Very pleasant read, keep it up @vadymmarkov 🚀

[zenangst]

From:

The first step is to declare a command. Your command type has to conform to
Aftermath.Command protocol and the Output type must be implicitly specified.

To:

The first step is to declare a command. Your command type has to conform to the
Aftermath.Command protocol and the Output type must be implicitly specified.

[zenangst]

Love this part 😁

[zenangst]

From:

Note that any type can play a role of Output, so if we want to add a date
to our BookUpdateCommand it could look like the following:

To:

Note that any type can play the role of Output, so if we want to add a date
to our BookUpdateCommand it could look like the following:

[zenangst]

From:

Command is an intention that needs to be translated into action by handler.

To:

Command is an intention that needs to be translated into an action by a handler.

[zenangst]

Command handler is responsible for publishing events to notify about results of
the operation it performs. Command handler type has to conform to
Aftermath.CommandHandler protocol that needs to know about the command type
it will work with:

The command handler is responsible for publishing events to notify about results of
the operation it performs. The command handlers type has to conform to
Aftermath.CommandHandler protocol, that needs to know about the command type
it will work with:

[zenangst]

From:

Fact works like notification with no async operations involved. It could
be used when there is no need to have a handler and generate an output. Fact is
already an output itself, so the only thing you want to do is notify all
subscribers that something happened in the system, and they will react
accordingly. In this sense it's closer to a type-safe alternative to
NSNotification.

To:

Fact works like notification, with no async operations involved. It can
be used when there is no need for a handler to generate an output. Fact is an
output itself, so the only thing you want to do is notify all
subscribers that something happened in the system, and they will react
accordingly. In this sense it's closer to a type-safe alternative to
NSNotification.

[zenangst]

From:

Middleware is a layer where commands and events could be intercepted before
the moment they reach listeners. It means you can modify/cancel/extend the
executed command in Command Middleware, or do appropriate operation in
Event Middleware before the published event is received by its reactions.
It's handy for logging, crash reporting, aborting particular commands or
events, etc.

To:

Middleware is a layer where commands and events can be intercepted before
they reach their listeners. It means you can modify/cancel/extend the
executed command in Command Middleware, or do appropriate operation in
Event Middleware before the published event is received by its reactions.
It's handy for logging, crash reporting, aborting particular commands or
events, etc.

[zenangst]

From:

Naming is hard. I doesn't seem right to have names like BookListCommand,
BookListCommandHandler and BookListWhatever in the project. Here comes the
idea of stories that group related types and make the flow more concrete:

To:

Naming is hard. It doesn't feel right to have names like BookListCommand,
BookListCommandHandler and BookListWhatever, does it? If you agree, then you can work
around this issue by introducing a new idea into the mix.
You can group all related types into stories, which makes the flow more concrete.

[zenangst]

From:

In this sense it's close to user stories used in agile software development
methodologies.

To:

In this sense, it's close to user stories used in agile software development
methodologies.

[zenangst]

From:

We believe that in iOS applications in most of the cases there is no real need
for single global state (single source of truth) or multiple sub-states
distributed between stores. Data is stored on disc in local persistence layer,
such as database and cache, or it's fetched from network. Then this content,
assembled piece by piece from different sources, is translated into the
"view state", which is readable by the view to render it on the screen. This
"view state" is kept in memory and valid at a given instant in time until we
switch the context and the current view is deallocated.

To:

We believe that in iOS applications, in most of the cases, there is no real need
for single global state (single source of truth) or multiple sub-states
distributed between stores. Data is stored on disc in local persistence layer,
such as database and cache, or it's fetched from network. Then this content,
assembled piece by piece from different sources, is translated into the
"view state", which is readable by the view to render it on the screen. This
"view state" is kept in memory and valid at a given instant in time until we
switch the context and the current view is deallocated.

[vadymmarkov]

Thanks @zenangst ! Fixed your comments in this commit 5db9101