Bugfix: 'ref' not available reliably #200
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.
Issue: Discovered this while working on a prototype slider control:
bryphe/prototype/slider
.Snippet of code with the issue:
Defect: The
ref
would not be available reliably. Theref
callback is being called correctly, but when we usesetRef
it's happening at a time when the instance hasn't been mounted completely in the reconciler - so it's not able to persist the state. Later renders give backNone
.Fix: My proposed fix for this is to have this event be 'queued' such that we only dispatch it when reconciliation is complete. This is doable since we have the
ref
model implemented completely in 'user-space' - in other words,reason-reactify
doesn't modelref
today.This would create an event queue for nodes - and only dispatch it on request (which
revery
will flush these pending events after every render).Open Questions
ref
as a primitive by default inreason-reactify
. If so, would it make sense to have auseRef
hook we include as well? If we push it to the framework - we might be able to come up with a more efficient implementation.ReactMini
and mentioned in Hooks with slots reason-reactify#51 - which also makes me consider that the reconciler would be the right place to push-back this fix. Depending on how that issue is fixed - I suspect the batching updates - enforcing that 'useState' is called at a correct time with more precision - would also address the issue.TODO:
Node
module