Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Dealing with unstyled text

See original GitHub issue

Problem

So we currently use React components that render regular old text DOM nodes a la <h1>, <span>, etc… By default, we do not style these nodes in Operational, but instead expose a suite of Typography components: <Body>, <Heading1>, etc. that are among the former nodes but with styling.

Because of this, the regular old DOM nodes are unstyled. This looks pretty ugly.

Proposed Solution

I’ve thought of the following two solutions:

Solution 1: `<StyledText>`

A component that wraps whatever is in it, and applies the same styling as Heading1 does to h1s to the underlying DOM node. In terms of implementation, it would be

const StyledText = styled("div")`
  h1 {
    whatever happens in Heading1's styles here
  }

  span {
    you get the idea
  }
`

Anything in that div would then look as expected. I am not in favor of this approach because:

It adds an extra node to the DOM and to the React tree.
Still allows breaking Operational’s opinionation because we’ll have unstyled text in places where this has been forgotten.

Solution 2: Using `<OperationalUI>` the way it was intended

If we hoist these styling settings to the top-level provider, we have an opinionated library that styles all text out of the box, and does not require wrapping text in React components like React Native does.

I feel this is more of an idiomatic approach: wrap once, forget about it – your text is always beautiful.

Thoughts?

Issue Analytics

State:
Created 5 years ago
Comments:9 (9 by maintainers)

Top GitHub Comments

3reactions

peterszerzocommented, Aug 29, 2018

@TejasQ the advantage of localizing at a lower level is that it is much less likely for CSS rule conflicts and overrides to occur between global p styles and styles a random p tag gets through its local parent component. In the current intended usage at least, it is unlikely that we’ll put other components inside <StyledText>, whereas if we add the styles to <OperationalUI>, global styles will apply to every component.

This is indeed convenient, but it is also dangerous, and I think we should be really careful with introducing possible overrides. What will happen when we change the Heading1 component and open it up for an override it previously protected itself from? What happens when something changes in the emotion implementation that will render the global styles after the local ones, causing our apps to look different after an overnight patch release? Are we willing to spend extra time debugging style regressions?

I’m sure there are reassuring answers to these concerns, but I’d rather avoid thinking about them in the first place.

2reactions

ImogenFcommented, Aug 29, 2018

I agree, we don’t want a CSS war. We had this to a certain extent in the old frontiamo and metriamo repos - trying to figure out where a particular bit of CSS came from originally, or why specific CSS wasn’t being applied, was a nightmare at times.