Skip to content

fix: eventsRef should trigger the lastest version of config callbacks#521

Merged
shuding merged 4 commits intovercel:masterfrom
Lam9090:master
Aug 4, 2020
Merged

fix: eventsRef should trigger the lastest version of config callbacks#521
shuding merged 4 commits intovercel:masterfrom
Lam9090:master

Conversation

@Lam9090
Copy link
Copy Markdown
Contributor

@Lam9090 Lam9090 commented Jul 14, 2020

fix

Resolve: #508 #515

Now the eventsRef read the config via the ref,which always capture the lastest version of the config callbacks.

This fix the problem of the stale closure related to the config callbacks.

* Currently,the config callbacks captured by the eventsRef is the callbacks created in the initial render of the component.

* If the config callbacks is pure, everything is fine

* but if the config callbacks rely on some variables of the components , it would cause some bugs related to the stale closure.
@Lam9090
Copy link
Copy Markdown
Contributor Author

Lam9090 commented Jul 14, 2020

cc @sergiodxa

@Lam9090
Copy link
Copy Markdown
Contributor Author

Lam9090 commented Jul 14, 2020

Also, i've noticed some code paths that using the config may have some similar stale closure problem.
Should we consider the scenario the config passed to the useSWR hook may change along the component lifecycle?

)

const lastestConfig = useRef(config)
useIsomorphicLayoutEffect(() => {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we need to have this useEffect here, could it just be updated in each rendering directly?

const configRef = useRef(config)
configRef.current = config

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@huozhi I feel that we still need to wrap it with useEffect (useIsomorphicLayoutEffect here). Updating refs directly in render can be dangerous in Concurrent Mode (not 100% about this specific usage here).

I'll approve this for now, but I suggest adding a comment to clarify 👍

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, good to know there's side effect on concurrent mode! 🙏 sorry for my unreasonable comment above

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shuding thanks to point this out,do i need to change this back?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, I think you can just simply revert the last commit. the rest looks good 👍

Copy link
Copy Markdown
Member

@shuding shuding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lintuming Thank you so much for this great idea and also creating so many tests! Great work! 🙏

@Lam9090 Lam9090 requested a review from shuding July 27, 2020 02:31
Copy link
Copy Markdown
Member

@huozhi huozhi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

@nicholaschiang
Copy link
Copy Markdown

@shuding @huozhi @lintuming could we merge this?

@shuding shuding merged commit dc6e94a into vercel:master Aug 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

onError callback not reflecting component state changes

4 participants