Performance optimizations

[aduth]

Loving this component so far! However, in my own usage, and even in the demo site, there's a noticeable lag when attempting to enter text into fields at a reasonable typing speed. Enabling the "trace react updates" option in Chrome React Developer Tools, it becomes apparent that the entire form is re-rendered any time an input changes.

I haven't dug into the code, but it would seem reasonable to implement shouldComponentUpdate (perhaps simply with pure-render-mixin) to prevent rerendering of components not affected by the change in form values.

[Natim]

Thank you for this report 👍

[n1k0]

If we want to properly implement shouldComponentUpdate, we'll have to rely on some immutable library like Immutable.js, which was something I tried to avoid.

But I agree the impact on performances on lower end machines might get really important, so we should do this upgrade.

(And yeah, kudos for the super clean and useful report.)

[aduth]

If we want to properly implement shouldComponentUpdate, we'll have to rely on some immutable library

Again, pardon my ignorance of the codebase and whether these suggestions have already been considered, but it's quite possible to perform shallow comparison (i.e. pure render) even with plain object properties, so long as you're careful not to mutate the original when updating.

Object.assign( {}, original, { input: 'New Value' } );

Or, for deeply nested objects, consider pulling in lodash.merge (available as standalone package):

merge( {}, original, { foo: { bar: { input: 'New Value' } } } );

[n1k0]

The problem is not with copying/merging deeply nested objects, it's with comparing them to know if they've changed.

({a: 1, b: {c: 2}}) === ({a: 1, b: {c: 2}}) // false

And shouldComponentUpdate needs to return a boolean to trigger a render when things have changed. So we need immutable data structures which don't carry identity as plain js objects do, so we can safely compare them and return the appropriate boolean value there.

Am I missing something obvious? I didn't have my first coffee of the day just yet.

[leplatrem]

Does this affect the demo only or the form rendering itself?

[aduth]

@leplatrem : I'm observing it in my own usage as well, but the demo was the easiest way for me to illustrate the problem.

[magopian]

It may be related to kinto-admin, but when viewing a page with a few hundred records (for the blocklist), the page is very laggy, unresponsive, and even freezes for a couple of seconds at the beginning.

[aduth]

Might be compounded with the fact that JSON schema validation is performed on every change:

https://github.com/mozilla-services/react-jsonschema-form/blob/afcb38e/src/components/Form.js#L51

[n1k0]

This is probably the very first thing to investigate as a solution https://facebook.github.io/react/docs/shallow-compare.html

[yogeshwar-woodside]

Hello, I am experiencing this issue with v4 and it is causing performance bottleneck in react-native mobile app.

It appears that entire form re-renders on ANY field change.
We are particularly having large forms (90+ fields), and expected to have larger and complex forms in future.

How can this be improved?
Is there any way in which only affected fields are re-rendered instead of entire form?

I have carried out the experiment using v5.
It's evident form the screenshot that Form element re-rendered for every character entered in last name. 9 chars = 9 renders

[Sushil3663]

I have used a custom debounce of 2 seconds in onChange to improve type speed as a temporary solution
--- const debouncedOnChange = useDebounce(onChange, 2000);