Add a note about needing safeRenderCompletion and slow CPU:s #544
Conversation
On slow CPUs safeRenderCompletion needs to be set to make sure RJSF waits for setState before calling onChange. As discussed in rjsf-team#446.
There was a problem hiding this comment.
Thanks for your effort, and your patience since I'm only getting to this now 😳. I'm still quite new to the project so I'm not comfortable merging this without a clearer understanding of what safeRenderCompletion is and why it isn't the default (which I'll try to get from @n1k0). I've left a couple comments in case you are more comfortable with the architecture than I am :)
| > Note: Prior to v0.35.0, the `options` prop contained the list of options (`label` and `value`) for `enum` fields. Since v0.35.0, it now exposes this list as the `enumOptions` property within the `options` object. | ||
| > Notes: | ||
| > * Prior to v0.35.0, the `options` prop contained the list of options (`label` and `value`) for `enum` fields. Since v0.35.0, it now exposes this list as the `enumOptions` property within the `options` object. | ||
| > * If your custom widget only calls `onChange` when the user is blurring the field (maybe to keep RJSF from updating the model for every key stroke) there is an edge case where users on devices with less processing power could potentially submit stale `formData` when focused in an input field while submitting the form due to [RJSF util setState](https://github.com/mozilla-services/react-jsonschema-form/blob/master/src/utils.js#L495) not using the React `setState` callback unless we set the `safeRenderCompletion` prop to `true` on the `<Form>`component. |
There was a problem hiding this comment.
Wow, this is one complicated sentence. I'd like to break it up into smaller, more digestible chunks. I understand that there's a lot you want to convey -- there's an edge case, it happens in these circumstances, this is why it happens, and here's the workaround -- but I think each of those could even be a whole sentence. Maybe we should start with the symptom (submitting with stale data?) since that's the thing someone might notice?
I just noticed that we don't actually document safeRenderCompletion anywhere, which makes me think it's a hack used for tests. But because it's a prop of the form, rather than any specific widget, I wonder if we should document it somewhere more global instead?
|
|
|
The funny thing is, we went for only updating the But I believe that's more of a Material-UI problem which hopefully will be solved when they're done with their rewrite so I'm fine with this not getting merged or documented. |
|
I waste 3 hours to figure out why my onChange function doesn't give me the changed data. I understand you may have some reason to add this config option, but you really shouldn't set it to |
|
Closing this because we no longer use safeRenderCompletion. |
On slow CPUs safeRenderCompletion needs to be set to make sure RJSF waits for setState before calling onChange.
Reasons for making this change
See the discussion in #446.
Checklist