-
Notifications
You must be signed in to change notification settings - Fork 841
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
[Emotion] Convert global className
utilities
#6124
Conversation
className
utilsclassName
utilities
+ fix missing CSS logical property on text truncation mixin + convert textLeft/Right to logical CSS - note that we can't use the logicalTextAlign util for this as !important can't be passed to that util
a2c7201
to
2b68854
Compare
.eui-isFocusable:focus { | ||
// Forcing focus ring on non-EUI elements | ||
${euiFocusRing(euiThemeContext)} | ||
} |
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.
Question: is this global utility still valid? I'm not seeing any uses either in Kibana or EUI, and I feel like our *:focus
reset should basically already covers this:
eui/src/global_styling/reset/global_styles.tsx
Lines 87 to 89 in 6d390a2
*:focus { | |
${euiFocusRing(euiThemeContext)} | |
} |
Thoughts?
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.
It seems that it was being used in an old version of EUI: https://github.com/lcawl/eui/blob/8073430a578673eb9944c20cc39ef0752c9aadc4/src-docs/src/views/guidelines/colors/core_palette.js#L51.
I couldn't find any uses in Kibana and in recent versions of EUI. So I would say it's safe to delete.
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.
Fantastic, I'll go ahead and delete it. Thanks @miukimiu!!
edit: 626c66f
Preview documentation changes for this PR: https://eui.elastic.co/pr_6124/ |
+ convert euiFullHeight Sass mixin to Emotion + move @mixin euiFullHeight to `mixins/_helpers` instead of living in `_utility`
- since that's where the className was documented
- this requires adding a new `logicalCSSWithFallback` util, since overflow-inline/block is not yet supported on non-FF browsers + fix incorrect overflow mapping - inline should be x and block should be y
+ convert mixin to accept the entire euiThemeContext instead of just the euiTheme to match all other mixins
Preview documentation changes for this PR: https://eui.elastic.co/pr_6124/ |
Preview documentation changes for this PR: https://eui.elastic.co/pr_6124/ |
Hey @breehall! If you have a time this week, do you mind helping code review this PR? Thank you! |
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.
Thanks for converting these global className
utilities. LGTM! 🎉
@@ -81,10 +81,10 @@ export const euiBreadcrumbContentStyles = (euiThemeContext: UseEuiTheme) => { | |||
// Types | |||
page: css` | |||
&:is(a):focus { | |||
${euiFocusRing(euiTheme, 'inset')}; | |||
${euiFocusRing(euiThemeContext, 'inset')}; |
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.
Much better! 🥳
@@ -34,8 +35,7 @@ export const euiGlobalToastListStyles = (euiThemeContext: UseEuiTheme) => { | |||
${logicalCSS('bottom', 0)}; | |||
${logicalCSS('width', `${euiToastWidth + euiTheme.base * 5}px`)}; /* 2 */ | |||
${logicalCSS('max-height', '100vh')}; /* 1 */ | |||
overflow-y: auto; // Fallback for the 'overflow-inline' logical property, which is not yet supported | |||
${logicalCSS('overflow-y', 'auto')}; | |||
${logicalCSSWithFallback('overflow-y', 'auto')}; |
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.
That's a great idea. 🥳
@@ -84,7 +84,7 @@ export default () => { | |||
<p> | |||
To mask the top and bottom of the scrolled content, indicating | |||
visually that there is more content below, pass in true to the | |||
second paremeter <EuiCode>mask</EuiCode>. | |||
second parameter <EuiCode>mask</EuiCode>. | |||
</p> | |||
<p> | |||
<EuiCode>{"useEuiOverflowScroll('x', true);"}</EuiCode> |
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.
Something that we need to decide as a team. We normally document the hooks instead of the function versions. But I use much more functions than hooks. Why? Because in component.styles.ts
we can't use hooks.
If we search for useEuiShadow
we find 0 usages in EUI. But euiShadow
is being used multiple times. So I wonder if we should be documenting both functions and hooks or prefer documenting the functions rather than hooks.
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.
Our docs are consumer facing, so we document the hooks because we expect consumers to be using hooks more than passing our euiThemeContext
around. Internally in EUI we pass our theme around a lot, but consumers are much less likely to do so, so they'll probably just want a hook that handles getting the theme for them.
TBH, this is kind of an architectural choice we made too when setting up our Emotion styles pattern. We could have decided to make all our styles files/functions hooks instead, e.g. useEuiComponentStyles()
which then allows us to call hook utils of all our styles instead of having to pass euiTheme
around manually. But then hooks can't be called conditionally or in callbacks, so there's pros/cons to everything.
cc @thompsongl for more thoughts
${logicalCSS('width', '100% !important')} | ||
} | ||
.eui-fullHeight { | ||
${euiFullHeight()} |
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 is something that I never know... When we're calling functions should we end the line with semicolons?
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.
Most of our functions are already fully fledged CSS line(s) and contain their own ending semicolon, so I remove the extra semicolon after use because it's unnecessary (although Emotion/CSS is smart enough to ignore extra semicolons).
A few functions do not have the trailing semicolon (although that's not common) so those will need it. Essentially It depends on the function; you may have to right click / trace the function to check its output.
+ already being handled by global reset
Preview documentation changes for this PR: https://eui.elastic.co/pr_6124/ |
Summary
I strongly recommend following along by commit, as I did a few extra side cleanup items (missing logical properties, mixin API updates, documentation) alongside the global conversions.
Checklist
- [ ] Props have proper autodocs and playground toggles- [ ] Checked Code Sandbox works for any docs examples- [ ] Checked for accessibility including keyboard-only and screenreader modes- [ ] Updated the Figma library counterpart