Comment by skrebbel | Hacker News Reader

Comment by skrebbel | Hacker News Reader

I suspect my knowledge is behind the times, but I never understood the appeal of putting stuff like "current thread" in the app state at all. To me, it makes much more sense if the stores (or the single data tree, in the redux case) just contain the flat dumb data, and the URL is used to pick the relevant data that the components need. This way, no state is duplicated anywhere, the stores are dumb, and the URL is leading.

This is how most server side MVC frameworks work too, it makes server-side rendering super simple (even with shared app state between users), it fits with RESTful designs, it forces you to design state into URLs so users can share links by definition, and so on. It just seems obvious to me.

But somehow, Flux and most things derived from it seem to disagree and insist on storing the "this is what the user looks at right now" information in the application state. To me, that hopelessly convolutes things. But I've been wrong before and I'd like to learn.

Can anyone explain to me why that's better? I might just be a conservative, grumpy old man here.

There may be some state that belongs in the URL and some that doesn't. The threat currently read should certainly be in the URL to facilitate sharing/bookmarking etc. But, for example, the state of some checkboxes or a dropdown or values in input element – while being part of state – don't feel like they belong in the URL.

I've actually been struggling with some of these. For example, whether a dropdown is expanded or not is state, but it just doesn't feel 'big' enough to even be in the reflux store. Plus it turns out to be a major hassle to implement such a dropdown, with actions firing the new state all the way up to the store and the state then being passed down the whole chain of components.

Following redux orthodoxy here also precludes you from using existing libraries (bootstrap/jquery) and kinda leads to reinventing the wheel. I had no idea how much consideration a simple dropdown takes until I looked at the bootstrap/jquery source for it.

I think it's the opinion of most React developers that state specifically pertaining to the presentation of UI controls (and not the general UI, which of course depends on Flux state) can be left in the React component. They do, after all, support having their own state - so that functionality should be utilized. Also declutters your app state.

For common components like Dropdowns, DatePickers, etc, I've been using Kendo UI Core with a set of simple wrappers to make them (mostly) stateless:

https://github.com/guscost/kendo-react-wrappers

Perhaps not acceptable for performance-critical or first-class consumer-facing UIs, but you get nice cross-browser compatibility and pre-built widgets that can be surprisingly complex.

So, if I see this correctly, these components save their state in a global object, and that is supposed to persist state on re-renders? I get how this can be considered somewhat 'dirty', but can you elaborate on the performance implications?

The global KW object is just a namespace for the widget wrapper components. You'd have to reference the Kendo UI Core library and then the KW.js script before rendering your components containing e.g. <KW.DatePicker /> as in the readme.

Internally the Kendo library is going to maintain its own state and manipulate the DOM elements needed for each widget, and I only know a bit about how that works. Most of these wrappers only run render() once because React would throw all kinds of errors if it tried to diff the DOM inside the components.

Updates are handled in componentWillReceiveProps, and whenever the component can be updated with the new props without destroying and recreating itself, the updates happen via the Kendo API (after the wrapper checks if the new value is different). This means that for common use cases these wrappers should perform just about as well as the widgets do normally. Also every controllable setting is exposed as a prop, and the props are synchronized on every update. Props that are not passed in are reset to the defaults, meaning these widgets should appear stateless to the containing component.

The react-kendo project[0] uses some very cool introspection to provide full support for all the Kendo widgets, and it looks like it should be reliable and stateless. However it destroys and rebuilds the widget on every update. While that probably isn't going to be a huge performance hit it certainly makes a difference.

https://github.com/tjwebb/react-kendo

well, when you use redux to manage the router state, you get the best of both worlds.

"current thread" doesn't need to be stored in the state in an explicit way. rather, you just need to be able to derive the "current thread" (or whatever) from the state.

so, your state contains the current route, and you use that to derive the "current thread" and then if redux has any state corresponding to that thread (or whatever) you can get that, too.

This might just be personal preference, but it seems that "current thread" is the more pure representation of (that part) of the current state, and the URL/route should be the derived attribute.

In that case, you can have a redux state reducer look for navigation actions, and set current thread. Either way works well with the flux/redux mental model. And in either case, you'll have to implement logic for mapping route -> current thread and vice versa ...

The thing is that a SPA doesn't correspond 1-1 with some REST endpoint -- it's comprised of many calls to different endpoints.

So the SPA's state is different than just "we're now pointing to this resource" -- much more full and complex.

Reply on news.ycombinator.com