diff --git a/_posts/2014-07-30-flux-actions-and-the-dispatcher.md b/_posts/2014-07-30-flux-actions-and-the-dispatcher.md index 87a46d16e..462df404b 100644 --- a/_posts/2014-07-30-flux-actions-and-the-dispatcher.md +++ b/_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/img/blog/flux-diagram.png b/img/blog/flux-diagram.png new file mode 100644 index 000000000..693f70335 Binary files /dev/null and b/img/blog/flux-diagram.png differ