@mejari - the reason why I wrote out the React code long-form is because I couldn't figure out how to write it concisely :) Not because I'm biased hehe.
I disagree it's not identical to React+Flux at all. There's more pieces and wiring required for the typical "Save" button example. In react+flux, the views need to listen on stores:
MyStore.listen(this._onMyStoreChange.bind(this));
The views manually call action creators:
MyActions.saveData();
Action creators dispatch separate events for beforeRequest, onRequest, onError events:
this.actions.onBeforeSaveSomething();
// do the save
this.dispatch({ type: 'SUCCESS', data: myData });
In the Flux flavor I'm using (alt), stores automatically dispatch events when their state is changed, but I found managing the store state is annoying because of the loading, error flags[1].
I guess it just comes down to comparing two different things. Yes, you have to do more setup with React because React isn't what Ext is. But if you set up your React to the point that Ext is at, with data binding and error handling and event listening that Ext magics away you get code that is very similar. Almost all of your code is doing what Ext magically does, but in a React application of any size these things are handled via components and mixins and such and you don't have to deal with them in the clunky way you're describing.
Not to keep harping on this issue because I know we're way off topic, but I'm genuinely curious how the React code can be simplified because this was one of my main pain points using React. Reflux and alt were major improvements over the Facebook flux impl, but they still require the boilerplate I posted above. If you remove that then you have "Flux magic" :)
There's no Ext magic in the code I posted. Flux and MVC are different patterns. In MVC, the controller typically has direct access to the view and model which is why the code is simple:
myView.setLoading(true);
myModel.save(...)
That would look the same in Java Swing for example. Flux is a fundamentally different pattern and one that I really haven't seen the need for in the products we're building to justify it's disadvantages. But for some applications, it's probably the right solution.
And the reason you couldn't setup your stores in a similar fashion?
myStore.setLoading(true);
myStore.save(...);
Where the handling is in your action handler for whatever event was raised... This assumes you do your backend data access in the store itself... there are other options.
No confusion.. you can have a property on your store that does the same to state, and triggers an event to draw a mask/modal in a similar way... there's nothing preventing you from doing that... it isn't so much in the box, but you can do it pretty easily.
You also aren't stuck building class based object constructors in JS as extjs projects tend to do.. or trying to shim out areas of extjs in order to extend a base rendering.
I also had issue with the amount of setup with React, which is part of what drove me to Mithril, which has almost zero boilerplate. Nearly every line of code you write is either relevant application logic or declarative view code.
I disagree it's not identical to React+Flux at all. There's more pieces and wiring required for the typical "Save" button example. In react+flux, the views need to listen on stores:
The views manually call action creators: Action creators dispatch separate events for beforeRequest, onRequest, onError events: Stores need to listen for action creator events: In the Flux flavor I'm using (alt), stores automatically dispatch events when their state is changed, but I found managing the store state is annoying because of the loading, error flags[1].So the store.onSave might look like this:
Finally, the view updates it's state in response to a store change which automatically calls render.Then in the view render, you can show your loading/saving mask.
[1] https://news.ycombinator.com/item?id=9315503