Performance: Improve input speed for widgets #34

Really cool to see this fork! It looks promising so far and I just want to pull over a commonly reported perf issue from NCMS as it was still an issue at the time of the fork... I'm happy to implement the change as well since I already did it over there. lol

Problem

Currently, typing in input fields works fine so long as a collection doesn't contain a lot of inputs and/or lists.

At a certain point when you have enough lists and inputs, the input delay basically ruins the experience. Having opened lists while typing multiplies the performance issue.

Cause

I believe the issue is that for each keystroke to any widget receiving text input, the redux store is recalculating its state and populating it to every single component. This change can take up to 300ms or more per key stroke for large data sets (think: kitchen sink with multiples of each widget, including multiple lists with widgets inside).

Possible fix

Debounce props.onChange in widgets that receive text input.

Affected widgets:

• Number
• String
• Text
• Markdown
• Code
• DateTime
• Color

Technical change should be straightforward although a bit tedious. Instead of always calling props.onChange, instead use a piece of internal state to quickly update the input value, and debounce the props.onChange handler (onChange is probably not a good name for this prop anymore, should be something like handleCollectionUpdate maybe?).

Tangent optimizations

Another thing I noticed is that collapsed List or Object widgets are still rendering their DOM, even though they're visually hidden. Completely unrendering those portions of the component would at least improve on reconciliation speed, although I'm sure it's negligible.

Alternatives / thoughts

I'm not sure if it will be possible to instead debounce the actual redux store update (but still continuously calculate the value so the draft state is still correct), but that would be the "smarter" approach. I still think regardless of that change, the inputs should maintain their state internally to ensure state is as fast as possible a la native html.

Another consideration could be to rearchitect the app so the collection data and UI state are more loosely coupled. As an example, any changes to the UI (via input or widget inclusion) trigger an update to the collection data, but the UI itself is only driven by the data on initial page load.