4 ms·

Ah, I understand now. It's always been clear that React alone isn't enough to write a full application; you need to combine it with some other pieces. The off

by Lazare 11y ago

Ah, I understand now. It's always been clear that React alone isn't enough to write a full application; you need to combine it with some other pieces. The official recommendation from Facebook is to use flux, and the most popular flux implementation (redux) is quite good, but you can also use Om-style approaches (Omniscient, Baobab, etc.), or wire it up to legacy Backbone models, or whatever. But you need something; you can't write an MVC app with only the V and expect good results. You guys tried to write a large "pure" React application, and it failed in all the ways that large React applications always fail. And you learned from it, and hacked together a kinda-sorta-fluxish solution, and it's working for you, and that's great. ...but if you want to take another look at it someday, I'd highly suggest checking out redux. It's very slick, and it was explicitly designed to solve the exact issues you ran into. (In particular, a redux app is built of a small number of smart components which respond to to a specific subset of events, each managing a tree of "dumb" components, which gives you the granularity you were looking for. And then you can use the PureRenderMixin and immutable data, which gives you the very fast shouldComponentUpdate methods you were looking for for free, no need to ever write your own since, as you found, that way lies madness. The docs even cover how to properly cache derived data, another issue you noted running into. And so on.)

Silhouette 11y ago
Sorry, but I think you have completely misunderstood me. We're not avoiding the popular Flux-style tools like Redux because we don't understand the need for a model behind the rendering components. We're avoiding them because they are nowhere near powerful enough out of the box for our data modelling and constraint enforcement needs. We're not kinda-sorta-fluxish, Flux is kinda-sorta where we were about five years ago on the Web side and probably closer to a decade ago if you include applications written in languages other than JS for native clients and the like. And we don't want to write a full application in React; we already have 90% of the application and we're just experimenting with whether React might offer a cleaner architecture for the easy bit in our next version.
- Lazare 11y ago
  Ah, that is a very different situation than I believed you were discussing. In which case...sure, that sounds logical. If you already have a good architecture and a very large, complex app, of course it's going to work better to keep the architecture you have than switching to the sort of naive React design that you'd normally find in a TodoMVC example project. :) (...of course, that doesn't really tell you much about React; seems like all you really learned is that badly architected apps perform badly. Not sure that one needed much testing. And of course, your initial comment seemed to be making a very different claim.)
  - Silhouette 11y ago
    I'm sorry if my earlier posts weren't clear. I mentioned the kind of scale we're working on in another post -- the previous version is under 100K lines of code so still not really that large or complex as UIs go. But yes, it's a little more challenging than TodoMVC. :-) In any case, our current view is that there is a useful middle ground where React may work well for us. The app in question predates just about all of the modern JS UI libraries/frameworks, at least in anything close to their current forms, so much of the rendering and event management code right at the front end is built with jQuery, early toolkits, and in many cases a lot of home-grown code. All of this still works pretty well, but quite a large proportion of it is functionality that every UI library in the universe provides today, so there's little reason to maintain another version any more. The rest of the app does have a good architecture that has stood the test of time, but for the next big update we're trying to solve much the same issues as everyone else with managing UI code as the app grows. React is of interest to us for several reasons, from being a useful templating mechanism, through providing a way of composing components that are relatively clean and modular in design, to its efficient DOM updates and declarative nature. These too are presumably the features that make it attractive to many of its users. But it is also of interest for this project precisely because its scope is tightly confined to just the rendering parts of the system and it doesn't try to lock the whole app into its own framework. We just confirmed early that some of the hype really is only that, and that scaling up to the kind of UI that has more than a few hundred data points on screen at one time is not as easy as some of the advocacy might suggest, so we're exploring how we can use the tool to take advantage of what it clearly does offer and play to its strengths without paying too high a price. In that respect, it's really no different to any other library we'd evaluate.

by Lazare 11y ago

Silhouette 11y ago

Sorry, but I think you have completely misunderstood me. We're not avoiding the popular Flux-style tools like Redux because we don't understand the need for a model behind the rendering components. We're avoiding them because they are nowhere near powerful enough out of the box for our data modelling and constraint enforcement needs. We're not kinda-sorta-fluxish, Flux is kinda-sorta where we were about five years ago on the Web side and probably closer to a decade ago if you include applications written in languages other than JS for native clients and the like. And we don't want to write a full application in React; we already have 90% of the application and we're just experimenting with whether React might offer a cleaner architecture for the easy bit in our next version.

Lazare 11y ago
Ah, that is a very different situation than I believed you were discussing. In which case...sure, that sounds logical. If you already have a good architecture and a very large, complex app, of course it's going to work better to keep the architecture you have than switching to the sort of naive React design that you'd normally find in a TodoMVC example project. :) (...of course, that doesn't really tell you much about React; seems like all you really learned is that badly architected apps perform badly. Not sure that one needed much testing. And of course, your initial comment seemed to be making a very different claim.)
- Silhouette 11y ago
  I'm sorry if my earlier posts weren't clear. I mentioned the kind of scale we're working on in another post -- the previous version is under 100K lines of code so still not really that large or complex as UIs go. But yes, it's a little more challenging than TodoMVC. :-) In any case, our current view is that there is a useful middle ground where React may work well for us. The app in question predates just about all of the modern JS UI libraries/frameworks, at least in anything close to their current forms, so much of the rendering and event management code right at the front end is built with jQuery, early toolkits, and in many cases a lot of home-grown code. All of this still works pretty well, but quite a large proportion of it is functionality that every UI library in the universe provides today, so there's little reason to maintain another version any more. The rest of the app does have a good architecture that has stood the test of time, but for the next big update we're trying to solve much the same issues as everyone else with managing UI code as the app grows. React is of interest to us for several reasons, from being a useful templating mechanism, through providing a way of composing components that are relatively clean and modular in design, to its efficient DOM updates and declarative nature. These too are presumably the features that make it attractive to many of its users. But it is also of interest for this project precisely because its scope is tightly confined to just the rendering parts of the system and it doesn't try to lock the whole app into its own framework. We just confirmed early that some of the hype really is only that, and that scaling up to the kind of UI that has more than a few hundred data points on screen at one time is not as easy as some of the advocacy might suggest, so we're exploring how we can use the tool to take advantage of what it clearly does offer and play to its strengths without paying too high a price. In that respect, it's really no different to any other library we'd evaluate.