[feat] Update useLayoutStyles to support REM type#12733
[feat] Update useLayoutStyles to support REM type#12733sfc-gh-lwilby merged 1 commit intodevelopfrom
useLayoutStyles to support REM type#12733Conversation
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
✅ PR preview is ready!
|
useLayoutStyles to support REM type
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for REM (relative unit) type to the useLayoutStyles hook in preparation for an upcoming st.space feature that will support REM options. The change extends the existing layout system to handle REM units alongside the current pixel, stretch, and content dimension types.
Key changes:
- Added REM as a new dimension type with corresponding logic for width and height calculations
- Extended type definitions and function signatures to support REM values
- Added comprehensive test coverage for REM dimension handling
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
frontend/lib/src/components/core/Layout/useLayoutStyles.ts |
Adds REM dimension type support, extends width/height calculation logic, and updates function signatures |
frontend/lib/src/components/core/Layout/useLayoutStyles.test.tsx |
Adds comprehensive test cases for REM width, height, and flex behavior |
| type LayoutDimensionConfig = { | ||
| type: DimensionType | undefined | ||
| pixels?: number | undefined | ||
| rem?: number | undefined | ||
| } |
There was a problem hiding this comment.
suggestion: Consider using a data structure that enforces required fields on a per-type basis.
Right now, this is a valid object per this type that will pass the type-checker:
const dimension: LayoutDimensionConfig = { type: "pixel", rem: 100 }This is not actually correct, and it would be good for the compiler to prevent these kinds of situations to begin with.
We can use discriminated unions to achieve type safety in this scenario. For example:
type LayoutDimensionConfig =
| { type: "stretch" }
| { type: "content" }
| { type: "pixel"; pixels: number }
| { type: "rem"; rem: number }Now, the same example from before becomes a compiler error!
There was a problem hiding this comment.
Great idea, thanks!
There was a problem hiding this comment.
@sfc-gh-bnisco had to make a lot of changes in useLayoutStyles to support this. Could you take another look since it is quite different since Lukas approved now.
7cdc6e1 to
928bdf6
Compare
| let width: React.CSSProperties["width"] = "auto" | ||
| if (widthType === DimensionType.STRETCH) { | ||
| if (widthConfig.type === DimensionType.STRETCH) { |
There was a problem hiding this comment.
suggestion (non-blocking): Now that we have a union type to work with, another common pattern is to utilize a switch with assertNever on these code paths in order to get exhaustive compiler-time type checking.
Something like:
const { type } = widthConfig
switch (type) {
case DimensionType.STRETCH:
width = "100%"
case DimensionType.REM:
width = `${widthConfig.rem}rem`
// ... all the other cases
default:
assertNever(type)
}The benefit of this approach is that if the type union were to add a new member, this switch statement would become a compiler error until the new case is added. The intention here is to have the compiler proactively alert to the areas that need to be updated.
928bdf6 to
ee4f058
Compare

Describe your changes
Adds support to
useLayoutStylesfor REM type in preparation forst.spacewhich will support REM options.GitHub Issue Link (if applicable)
Testing Plan
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.