Add rerenderOnCallbackChange
#108
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the (v1.1.0), as reported in #103, the callbacks were not part of the
renderConfig'suseMemodependency array. Which means that if one of those callbacks gets updated, the widget won't re-render so the next callbacks invokations may use stale state.In #105 (v.1.2.0), the callbacks were added into the
useMemodependency array, so now if one of those callbacks gets updated, the widget re-renders. As that is intended, it silently introduces a bug where the widget may invoke the callbacks more than once, causing an "endless loading" or similar unexpected bahavior. This was reported in #107This PR introduces a
rerenderOnCallbackChangeprop to solve both issues (available in v.1.3.0).By default is set to false, so the behavior is exactly as it was in v1.1.0. If the user needs to re-render on callback updates, the
rerenderOnCallbackChangeprop should be set totrue, and also wrap the callbacks withuseCallback.