-
-
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
Convert @emotion/primitives
to TypeScript
#2849
Convert @emotion/primitives
to TypeScript
#2849
Conversation
🦋 Changeset detectedLatest commit: 03a4dcd The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
export interface AbstractStyleSheet { | ||
create<T extends NamedStyles<T> | NamedStyles<any>>( | ||
styles: T | NamedStyles<T> | ||
): T | ||
): { [P in keyof T]: number } |
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.
@types/react-native
has the return type as T
which seems wrong to me, and it was causing issues... This is the thing I am not totally sure is correct.
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 03a4dcd:
|
Codecov Report
|
expect(() => styled.TEXT({})).toThrow() | ||
}) | ||
|
||
test('should render the primitive when styles applied using object style notation', () => { | ||
const Text = styled.Text` | ||
color: red; | ||
font-size: 20px; | ||
background-color: ${props => props.back}; | ||
background-color: ${(props: any) => props.back}; |
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.
could we declare those props using generics rather than using any
?
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.
styled.Text
does not currently take any generic parameters. Are you suggesting we change the types so that it behaves similarly to styled
from @emotion/styled
? Meaning that on this line of code, TypeScript would know that props
has type TextProps
.
I believe that goes beyond just converting the package to TypeScript since it would mean changing user-facing types, but we can do that if you want to.
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.
styled.Text does not currently take any generic parameters. Are you suggesting we change the types so that it behaves similarly to styled from @emotion/styled? Meaning that on this line of code, TypeScript would know that props has type TextProps.
That would be ideal. It might not be the easiest task though - so let me know if you prefer not to do it right now.
I believe that goes beyond just converting the package to TypeScript since it would mean changing user-facing types, but we can do that if you want to.
Are there any user-facing types here though? I can't find any.
|
||
flatten(style?: unknown[]): unknown | ||
flatten<T>(style?: StyleProp<T>): T extends (infer U)[] ? U : T |
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.
Conceptually this might not be enough because flatten
accepts nested arrays, so this should be recursive.
I wonder though if this is even needed. It feels a little bit like maybe some kind of a style prop should be generic.
We already have not quite an accurate return type for the create method - in React Native Stylesheet.create
returns the input object, it's basically an identity function:
https://github.com/facebook/react-native/blob/ba383baf357bc6def94280d28f69efbab341fe36/Libraries/StyleSheet/StyleSheet.js#L371
What I'm getting at is that we personally don't quite care about all of those types internally - we should just treat them as close to unknown
as possible. We only need to make sure that given methods are available on the input StyleSheet
in places like here:
emotion/packages/native/src/base.js
Line 7 in 993557d
let styled = createStyled(StyleSheet) |
Maybe we should just make a StyleSheet
itself a generic? I'm not entirely sure about this but perhaps the best way to figure this out would be to convert this one together with @emotion/native
. I feel like it's hard to figure out those types in isolation right now because the final design needs to be dictated by the needs of both @emotion/primitives
and @emotion/native
.
An offtopic note - I wish we didn't have those libraries at all 😅
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.
We already have not quite an accurate return type for the create method - in React Native Stylesheet.create returns the input object, it's basically an identity function:
I could have sworn I tested StyleSheet.create
and it returned an object whose values were numbers... I think they might have changed that in a semi-recent version of React Native. Anyway, I have corrected the create
return type so that it matches @types/react-native
.
I feel like it's hard to figure out those types in isolation right now because the final design needs to be dictated by the needs of both @emotion/primitives and @emotion/native.
Yes, it is hard to figure them out in isolation. So do you think I should convert @emotion/native
in this PR?
An offtopic note - I wish we didn't have those libraries at all 😅
Totally agree LOL, I don't see how Emotion would be beneficial when using React Native...
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.
Yes, it is hard to figure them out in isolation. So do you think I should convert @emotion/native in this PR?
Yeah, alternatively - you could branch off this PR and prepare @emotion/native
migration as a separate PR that would target this PR instead of ts-migration
branch. This way we gonna be able to land and review both separately but at the same time, those types here wont be developed in isolation.
3189b0c
to
03a4dcd
Compare
Good points @Andarist . I am going to...
|
04c9f33
to
1effaf9
Compare
Part of #2358.
I'm not super confident this is correct, but 🤷♀️. This is mainly in reference to the one comment I about to leave on the PR diff.
This also removes some
.d.ts
files that got brought intots-migration
when I mergedmain
yesterday.CI is going to fail on this because of the Emotion website — I addressed this issue in a separate PR.