I've used Flux now on a few toy microprojects and I found that while Flux's unidirectional data flow is initially appealing (and I naturally tend to write unidi

I've used Flux now on a few toy microprojects and I found that while Flux's unidirectional data flow is initially appealing (and I naturally tend to write unidirectional code for very complex UIs in past apps),it makes the simple cases much more tedious and error prone. For example, given the simplest case of a Flux store handling events from a single ajax call, I find I have to write code like this: onLoad() { this.loading = true; this.errorMsg = null; this.data = null; this.condition1 = null; this.condition2 = null; this.something = null; } onSuccess(data) { this.loading = false; this.errorMsg = null; this.data = data; this.condition1 = data.blah === 'Hello'; this.condition2 = data.blah2 === 'World'; this.something = data.something; } onFailure(errorMsg) { this.loading = false; this.errorMsg = errorMsg; this.data = null; this.condition1 = null; this.condition2 = null; this.something = null; } If for some reason I was feeling crazy and I wanted the store to handle a second Ajax call, the store code becomes much more cumbersome so I avoid this. Even with some of the slicker Flux implementations, I still have tons more boilerplate than a traditional MVC app which for the simple UIs makes the code more difficult to reason about. For example, I find that in my store, I frequently forget to "reset" some property thus making the state "invalid". I've come up with this type of pattern, but it just feels... odd: resetInitialState() { this.loading = false; this.errorMsg = null; this.data = null; this.condition1 = null; this.condition2 = null; this.something = null; } onFailure(errorMsg) { this.resetInitialState(); this.errorMsg = errorMsg; }