6 ms·

We're in the process of migrating from ExtJS to React, and it is, to put it simply, awesome. Ext was great when we started because it gave us all these great ou

• nogridbag 11y ago
  Is your main complaint over theming ExtJS? We're also building enterprisey software that's for the most part not consumer facing. Our clients are much more concerned about functionality. So while we have several custom themes for our products, we haven't drastically altered the base themes. Regarding boilerplate, I'll give you a simple example. In ExtJS 4, it's one line of code to wire up an event handler in your controller to a view component like a "Save" button. Then in your onSaveButtonClicked event handler in your controller, you typically you write something like: myView.setLoading(true) // to mask the view myModel.save() // to execute an Ajax req, on success, myView.setLoading(false) In React+Flux, clicking the Save button calls an action creator. The action creator first fires an event "loading: true" before it does anything. A store which is bound to that load action then calls a method which dispatches another event. The view which is listening on the store is notified that "something changed" and redraws itself (to show the loading mask/spinner). All this and we haven't even begun loading any data yet. Repeat all steps once the data is loaded or if an error occurs. I'm not against React at all - just for our purposes ExtJS seems like a better fit. To be fair, I did spent some time building a custom URL router which really simplifies everything. All of our controllers are consistent with start() and stop() methods, they can define data dependencies (i.e. this data needs to be loaded before start is called), etc.
  • mejari 11y ago
    It's not the over-theming (although that is part of what creates that easily-recognizable Ext-ness), it's the strictness with which they expect you to use their components. If you want a dropdown that functions exactly the way Ext made a dropdown it is the easiest thing in the world, but if you want a slightly different behavior then it's a whole rigamarole of events and overrides and stuff. It's not just how it looks but actual functionality that is hard to improve. You'd be frightened if you saw our "ExtOverride.js" file. :) I should have also caveat-ed that we are on ExtJS 3, so ymmv with 4. The way you've concisely written the Ext code and long-form written out the React code does show some form of bias, as what you're really doing with React is pretty much the same as how you've written the Ext code, but if you write out the full path of any kind of UI update it will seem more complex. I mean, adding "the store is notified that something changed and redraws itself to show the loading mask/spinner" is what, 2 lines of code? But a long-form explanation makes it seem like a bigger deal. Your Ext code is missing all the logic to actually set up the Ajax stuff, all the event handling that you call out in React, error handling, etc... If you came into a React system with all the same things set up that you're assuming in your Ext system (data bindings, event handling, visual components) then the code to accomplish the same thing looks almost identical. As I said, Ext is great if you want to do what Ext wants you to do. It magics away a lot of stuff that you have to call out explicitly with React+Flux. But the second something goes wrong or you want to try something else that magic bites you in the ass. All I can say is that my experience switching from Ext to React has been one of massive amounts of time wasted figuring out the quirk of event flows and component layout hierarchies to front-end code that just makes sense and does what you'd expect and is ridiculously simple to debug.
    • ylem 11y ago
      To be fair, I think that ExtJs 4 offered a number of improvements over 3--but also introduced a lot of backwards incompatibility...
  • nogridbag 11y ago
    @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 }); Stores need to listen for action creator events: this.bindAction(actions.onBeforeSaveSomething, this.onBeforeSaveSomething); this.bindAction(actions.onSave, this.onSave); this.bindAction(actions.onError, this.onError); 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: this.loading = false; this.error = null; this.data = data; 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 https://news.ycombinator.com/item?id=9315503
• ylem 11y ago
  I've also been thinking about migrating away from Ext--on the one hand there are theming issues--on the plus side, I rather like their grid widget. But, their licensing model just seems to keep changing and that worries me enough to want to move away. For example, now it's just not possible to buy a single developer seat.