Skip to content

Adapt to unified v9 api #670

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed

Adapt to unified v9 api #670

wants to merge 3 commits into from

Conversation

drcmda
Copy link
Member

@drcmda drcmda commented May 15, 2019

@drcmda drcmda changed the title V9 api Adapt to unified v9 api May 15, 2019
@aleclarson aleclarson changed the base branch from master to v9 May 15, 2019 13:06
@drcmda drcmda requested a review from aleclarson May 18, 2019 09:14
@aleclarson
Copy link
Contributor

@drcmda I have a git tip for you! Do this to easily rebase your PR onto its base branch.

git pull --rebase origin v9

@@ -32,7 +32,7 @@ const makeConfig = props => {

export function useTransition(input, keyTransform, props) {
// Coerce props to an object
props = callProp(props)
props = useMemo(() => callProp(props), [])
Copy link
Contributor

Choose a reason for hiding this comment

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

Nope, still not good enough. :)

This ends up caching props when it's an object, which isn't what we want.

Copy link
Contributor

Choose a reason for hiding this comment

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

Or is it? :P

Copy link
Member Author

Choose a reason for hiding this comment

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

for transition im not sure tbh, it's undefined atm. i never considered it updateable, items can update, but i've never seen someone mutate the config (it also doesn't have an updater for this reason).

Copy link
Contributor

Choose a reason for hiding this comment

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

For all hooks, re-rendering should always queue an update (unless a deps array is given). Just for consistency.

Copy link
Member Author

@drcmda drcmda May 20, 2019

Choose a reason for hiding this comment

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

They're mostly one-time slots, "enter" and "leave" only happen once, the "update" slot is a valid concern though. Initially transition didn't have "update" so i never thought about it as updatable. How do we want to define it? And is this something that v9 useTransition can do already?

Copy link
Contributor

Choose a reason for hiding this comment

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

The enter and leave props should still be updatable for future enters and leaves.

PS: We may want to remove the update prop now that the update function is always returned.

Copy link
Member Author

@drcmda drcmda May 27, 2019

Choose a reason for hiding this comment

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

Makes sense (enter/leave). The update prop is useful, it comes from d3 and has a specific meaning. It fires for all nodes that aren't either enter or leave. Like so: https://codesandbox.io/embed/26mjowzpr Makes it possible to treat the elements that have already been transitioned as generic springs again.

Copy link
Contributor

Choose a reason for hiding this comment

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

It might be cool to allow custom phases instead of (or in addition to?) the "update" phase. The custom phase would be derived from each item. I haven't thought much about it yet, but it could be useful for multi-phase transitions.

@@ -25,6 +25,8 @@ const makeConfig = props => {
}

export function useTransition(input, keyTransform, props) {
// Coerce props to an object
props = useMemo(() => callProp(props), [])
Copy link
Contributor

Choose a reason for hiding this comment

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

Note: This still needs fixing. 👀

@aleclarson
Copy link
Contributor

Closed in favor of #808

@aleclarson aleclarson closed this Sep 21, 2019
@aleclarson aleclarson deleted the v9-api branch February 23, 2021 23:35
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.

2 participants