4 ms·

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/bookmarkin

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.

iLoch 11y ago
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.
guscost 11y ago
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 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.
- matt4077 11y ago
  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?
  - guscost 11y ago
    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 https://github.com/tjwebb/react-kendo

iLoch 11y ago

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.

guscost 11y ago

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 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.

matt4077 11y ago
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?
- guscost 11y ago
  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 https://github.com/tjwebb/react-kendo