diff --git a/docs/_posts/2014-07-30-flux-actions-and-the-dispatcher.md b/docs/_posts/2014-07-30-flux-actions-and-the-dispatcher.md index 87a46d16ed..462df404bb 100644 --- a/docs/_posts/2014-07-30-flux-actions-and-the-dispatcher.md +++ b/docs/_posts/2014-07-30-flux-actions-and-the-dispatcher.md @@ -24,6 +24,8 @@ Different actions are identified by a type attribute. When all of the stores rec Letting the stores update themselves eliminates many entanglements typically found in MVC applications, where cascading updates between models can lead to unstable state and make accurate testing very difficult. The objects within a Flux application are highly decoupled, and adhere very strongly to the [Law of Demeter](http://en.wikipedia.org/wiki/Law_of_Demeter), the principle that each object within a system should know as little as possible about the other objects in the system. This results in software that is more maintainable, adaptable, testable, and easier for new engineering team members to understand. + + Why We Need a Dispatcher ------------------------ diff --git a/docs/img/blog/flux-diagram.png b/docs/img/blog/flux-diagram.png new file mode 100644 index 0000000000..693f703357 Binary files /dev/null and b/docs/img/blog/flux-diagram.png differ