-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Support dynamic value #3146
base: main
Are you sure you want to change the base?
Support dynamic value #3146
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 2fb22d4:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
|
packages/serialize/types/index.d.ts
Outdated
|
||
export type CSSInterpolation = InterpolationPrimitive | ArrayCSSInterpolation | ||
export type CSSInterpolation<Props = unknown> = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one actually shouldn't end up including functions in CSSObject
. We have 2 flavors of those interpolations:
- the ones that u can pass to
css
- and the ones that you can pass to
styled
and similar
The difference is that css
is a context-less call. We don't get access to any props
there (and we don't defer css
resolution) so this should be an error:
css({
display: () => 'flex'
})
That's why we have both ArrayInterpolation
and ArrayCSSInterpolation
here. A similar distinction should be introduced for those object styles.
But now... I'm not sure if this would satisfy your original goal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, I will revert this. I think it should be fine since we focus only for styled
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done! see 2fb22d4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be fine since we focus only for styled.
Cool! ❤️
Done! see 2fb22d4
Thanks. I'm soft-approving this PR now. I think we still need to tweak types a little bit but honestly - I need to give it more thought to determine how to do it in the least disruptive way. So I think, it's best for me to do it soon-ish since I don't have concrete advice right now on how this should be done.
I'll also give @emmatown a couple of days to give their opinion about this. If we don't merge it this week - please ping me later.
@Andarist Would you mind taking a look at this again? |
I think we can consider this to be approved but I still have to figure out how types should be structured and I have some other things on my plate right now (including figuring out how to integrate Emotion with the upcoming React 19). How urgent/blocking this one is for you? it might help me to prioritize this PR. |
I'd say the urgency is medium. We are in the process of migrating components to support both emotion and zero-runtime engine, some need dynamic callback support so those are blocked by this PR. |
What:
Add callback support for the value when serializing styles. For example:
Why:
How:
The change is mainly in emotion's
serialize
function. When the value is a function, just call it with the props and continue serializing the result the same as before.Checklist: