-
Notifications
You must be signed in to change notification settings - Fork 167
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
chore: Split out data attributes to separate files #75
Conversation
compressed-size: runtime library Size change: +0.01 kB
View unchanged
|
Allow arbitrary data-* props at runtime. On web, the check is only performed during development. To workaround Flow's lack of support for typing arbitary data-* props, a separate type is created just for data-* props which can be used to maintain an app's list of supported data-* props. Ref #71 Close #75
9a15d99
to
43b8181
Compare
I reworked this PR to:
Please take a look and let me know if it still looks OK to you. Thanks! |
I'll revisit this to use the approach we took for |
Allow arbitrary data-* props at runtime. On web, the check is only performed during development. To workaround Flow's lack of support for typing arbitary data-* props, a separate type is created just for data-* props which can be used to maintain an app's list of supported data-* props. Ref #71 Close #75
43b8181
to
7b5732a
Compare
Allow arbitrary data-* props at runtime. On web, the check is only performed during development. To workaround Flow's lack of support for typing arbitary data-* props, a separate type is created just for data-* props which can be used to maintain an app's list of supported data-* props. Ref #71 Close #75
7b5732a
to
b32baeb
Compare
// This type allows Meta to internally override it with an | ||
// internationalization type which is a string at runtime… | ||
// but Flow doesn't know that. | ||
declare type Stringish = string; |
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 will be a problem for the generated TS types. We should use explicit imports and avoid usage of any "globals".
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.
Yeah we can fix that pre-existing issue later after fixing internal and syncing
Stop-gap solution for #71
This is a simple refactor that splits out all definitions of
data-*
attributes to separate files. This makes it easier to maintain a separate list of supported attributes internally without the need for patch files etc.