Cristhian Duran
My dad is baldy
Do not forget to record. Just in case
- Why do we need this component?
- Research & findings
- Solution
- Future improvements + Action items
We tend to have many different ways of rendering text
- Using typography with MUI props
- Using typography with className
- Using typography with a mix of everything
Too many non-standard ways of customizing any text
- Strange font-size, line-height, etc
- Difficult to make an h1 to look like an h3
- Inspected every Typography use case to compile a list of all customizations we have
- Identified problems
- Invalid HTML syntax like onClick events
- Non-typography properties (margin, padding)
- "component" prop in Typography is too flexible: it allows you to use any valid HTML tag
- If you need to set a color from the theme there is no way for you to do it unless you use style or className
- Created LXBText. See it in action in Storybook
- Technical overview
- Uses an MUI Box with a valid typography HTML tag
- Logs a warning if using something else
- Why a Box? Because it allows us to pass many props that Typography doesn't
- Spread {...rest} so we can extend the use of this component
- We can safely use tooltips (Not new, Typography already supports this)
- We can use this as an escape hatch to use style and className (like the 404 page)
- <Debate>No margin should be allowed</Debate>
- Improve the typings for colors to avoid invalid combinations
- Would be useful to build components above LXBText?
- Example: <Heading1 />
- Avoid writing too many props
- Doesn't have unit tests haha
- Start reviewing MRs having this component in mind on new parts of the system
- Consider updating the HTML structure when Typography contains margin, padding, etc.
- Refactor of existing invalid onClick events tied to Typography
By Cristhian Duran