5 ms·

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://gi

by 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

by guscost 11y ago

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