chore(scss): migrate core mixin kibanaFullBodyHeight to Emotion#220494
chore(scss): migrate core mixin kibanaFullBodyHeight to Emotion#220494afharo merged 13 commits intoelastic:mainfrom
kibanaFullBodyHeight to Emotion#220494Conversation
|
Pinging @elastic/kibana-management (Team:Kibana Management) |
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
| .painlessLabMainContainer { | ||
| @include kibanaFullBodyHeight($bodyOffset); | ||
| } |
There was a problem hiding this comment.
I could have removed only this one... but I got carried over and ported all the CSS in this file 😬
|
|
||
| .euiColorPicker__emptySwatch { | ||
| position: relative; | ||
| } |
There was a problem hiding this comment.
I was not sure where this is leveraged, so I decided to keep it for now.
There was a problem hiding this comment.
That appears to be an EUI-specific css class; however, I find no reference of it the EUI repo. I tried jumping back in time to older versions, but its hard to search that way... still didn't find anything.
Given it is scoped to the Maps app (#maps-plugin id), and the color pickers on the layers seem to behave the same with it commented out (tested that), I personally feel confident in removing it.
ryankeairns
left a comment
There was a problem hiding this comment.
Tested full screen in Discover, Dashboard, and Maps. All work as expected.
Changes lgtm.
| <div id="react-maps-root"> | ||
| <div | ||
| id="react-maps-root" | ||
| css={css` |
There was a problem hiding this comment.
For performance reasons, we avoid inlining css inside components. Instead, we declare styles outside the component or memoize them when possible. Otherwise, the styles are re-serialized on every render. These are small (sub-millisecond) operations, but they accumulate—so as a rule, we should always avoid inline css unless absolutely necessary.
(Optimization I here: https://engineering.deptagency.com/optimizing-emotion-in-react)
| <div id="maps-plugin" className={this.props.isFullScreen ? 'mapFullScreen' : ''}> | ||
| <div | ||
| id="maps-plugin" | ||
| css={css` |
There was a problem hiding this comment.
For performance, avoid composing styles directly inside the css`` template. Instead, define static and conditional styles outside, and pass them as an array. This prevents re-serializing the template on each render and improves readability.
const mapsPluginStyles = {
display: 'flex',
flexDirection: 'column',
width: '100%',
overflow: 'hidden',
};
const fullscreenStyles = { height: '100vh !important' };
css={[kibanaFullBodyHeightCss(), mapsPluginStyles, isFullScreen && fullscreenStyles]}
(reference read: https://douges.dev/blog/taming-the-beast-that-is-css-in-js)
| css={css` | ||
| ${kibanaFullBodyHeightCss(bodyOffset)} | ||
| overflow: hidden; | ||
| flex-shrink: 1; | ||
| `} |
There was a problem hiding this comment.
The overflow and flex-shrink styles should be moved outside the component as a static object. But there's another issue here—we’ve recently agreed to avoid dynamic styles in css prop and use the style prop instead.
So the preferred approach is:
const mapsPluginStyles = {
overflow: 'hidden',
flexShrink: 1,
};
css={mapsPluginStyles} style={kibanaFullBodyHeightCss(bodyOffset)}
Note: kibanaFullBodyHeightCss should be refactored to return a plain object instead of a css string, so it can be used with the style prop:
export const kibanaFullBodyHeightCss = (additionalOffset = 0) => ({
height: `calc(
100vh - var(--kbnAppHeadersOffset, var(--euiFixedHeadersOffset, 0)) - ${additionalOffset}px
)`,
});
src/core/public/css_utils.ts
Outdated
| export const kibanaFullBodyHeightCss = (additionalOffset = '0px') => ({ | ||
| height: `calc(100vh - var(--kbnAppHeadersOffset, var(--euiFixedHeadersOffset, 0)) - ${additionalOffset})`, | ||
| }); |
There was a problem hiding this comment.
allowing a more free form input rather than integer px. This allows linking to vars, making other calculations, etc.
| @@ -19,11 +19,9 @@ import bg_bottom_branded_dark from './styles/core_app/images/bg_bottom_branded_d | |||
| // The `--kbnAppHeadersOffset` CSS variable is automatically updated by | |||
There was a problem hiding this comment.
File renamed because the linter complained about the name not following snake_case format.
| const dscDocsPageCss = css` | ||
| ${kibanaFullBodyHeightCss(54)}; // 54px is the action bar height | ||
| `; | ||
| const dscDocsPageCss = kibanaFullBodyHeightCss('54px'); // 54px is the action bar height |
There was a problem hiding this comment.
no need to wrap it in a css template. Slight perf improvement.
| export const mapFullScreenStyles = { | ||
| height: '100vh !important', | ||
| }; |
There was a problem hiding this comment.
intentionally not adding the type CSSObject because this type is not compatible with the style prop 🤷, and I'm using it there because it's a dynamic style.
jughosta
left a comment
There was a problem hiding this comment.
Data Discovery changes LGTM 👍
mattkime
left a comment
There was a problem hiding this comment.
Code changes look good and work well, thanks!
| * } | ||
| * const styles = useMemoizedStyles(componentStyles); | ||
| */ | ||
| export const useMemoizedStyles = (styleMap: StyleMap) => { |
There was a problem hiding this comment.
This is neat!
Not intended as a blocker, but I wonder if we don't achieve a decent enough developer UX when grabbing the euiTheme object from css prop on components (e.g.).
Then to get the style definition "statically" colocated outside components we could use TS like:
// css_utils.ts
import type { Attributes } from 'react';
// Helper type for getting CSS attribute from React
export type CSSAttribute = Required<Attributes>['css'];
export type StyleMap = Record<string, CSSAttribute>;
// somewhere_else.ts
import type { CSSAttribute, StyleMap } from 'css_utils'
const styles: CSSAttribute = ({ euiTheme }) => ({
'& + &': { marginTop: euiTheme.size.s },
backgroundColor: euiTheme.colors.backgroundBasePrimary,
body: '1vh',
// ...
});
<MyComponent css={styles} />
// or
const styles = {
container: () => ...
} satisfies StyleMap;
<MyComponent css={styles.container} />...but I'm not an emotion expert! Perhaps your way is more performant/easier to use.
There was a problem hiding this comment.
@mbondyra, can you help me answer this question? 😇
There was a problem hiding this comment.
Hey @jloleysens — it's mostly a performance thing 🙂 With this approach, all styles are memoized.
That syntactic sugar you mentioned can actually hurt performance, since the function runs and re-serializes styles on every render—even though it looks cleaner in the JSX. There's also a small mistake in this comment: elastic/eui#6828 (comment) — defining the function outside the component doesn't help, because it still runs on each render as long as it’s a function.
There was a problem hiding this comment.
Thanks for the explanation, that makes sense 👍🏻
Co-authored-by: Jean-Louis Leysens <jloleysens@gmail.com>
|
Starting backport for target branches: 8.19 https://github.com/elastic/kibana/actions/runs/15123770596 |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Async chunks
Page load bundle
History
cc @afharo |
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
|
Cancelling backport because there are breaking changes in some of the modified files. |
…astic#220494) Co-authored-by: mbondyra <marta.bondyra@elastic.co> Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com> Co-authored-by: Matthew Kime <matt@mattki.me> Co-authored-by: Jean-Louis Leysens <jloleysens@gmail.com>
…astic#220494) Co-authored-by: mbondyra <marta.bondyra@elastic.co> Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com> Co-authored-by: Matthew Kime <matt@mattki.me> Co-authored-by: Jean-Louis Leysens <jloleysens@gmail.com>
|
Starting backport for target branches: 8.19 https://github.com/elastic/kibana/actions/runs/15735705068 |
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
Summary
#214729 started migrating away from the mixin
kibanaFullBodyHeight.This PR removes the other usages and the mixin itself.