DEV Community: Andrii Miroshnychenko

Share complex style configs with styled-components

Andrii Miroshnychenko — Fri, 24 Feb 2023 22:09:09 +0000

Recently on a project we worked on the new set of form components for internal library.
Our stack includes styled-components and I want to share an approach, which might be useful for someone. No knowledge behind basics (styled and css utilities) of aforementioned library is needed.

Let's say we have an input component, with border and border-radius configured. We assume that it can resemble complex structure, so we'll use simple div as a wrapper

const StyledInputContainer = styled.div`
  border: 1px solid black;
  border-radius: 4px;
`

const Input = () => {
  return <StyledInputContainer>
           <input />  // Just for illustrative purposes, we won't build real Input here
         </StyledInputContainer>
}

Fine. What if we want to allow user to remove value by clicking on cross button? We can add it to our Input

+ const StyledClearButton = styled.button`
+   // other styles for button
+  `

const StyledInputContainer = styled.div`
  border: 1px solid black;
  border-radius: 4px;
+  display: flex;
+  justify-content: space-between;
`

const Input = () => {
  return <StyledInputContainer>
           <input />
 +         <StyledClearButton>X</StyledClearButton> 
         </StyledInputContainer>
}

Having button hanging all the time in the input might be distracting for user, we can show it only if container is hovered.

const StyledClearButton = styled.button`
+   visibility: hidden;
    // other styles for button
`

const StyledInputContainer = styled.div`
  border: 1px solid black;
  border-radius: 4px;
  display: flex;

+  &:hover {                     
+    ${StyledClearButton} {    // Way to create css cascade
+      visibility: visible;
+    }
+  }
`

const Input = () => {
  return <StyledInputContainer>
           <input />
           <StyledClearButton>X</StyledClearButton> 
         </StyledInputContainer>
}

Now the button will be visible only if container is hovered.
We can even add props to this setup. For example, if our input has errors, we want it to have red border.

const StyledClearButton = styled.button`
   visibility: hidden;
   // other styles for button
`

const StyledInputContainer = styled.div`
-  border: 1px solid black;
+  border: 1px solid ${props.error ? 'red' : 'black'};
  border-radius: 4px;
  display: flex;

  &:hover {                     
    ${StyledClearButton} {
      visibility: visible;
    }
  }
`

const Input = () => {
+ // error state is handled here
- return <StyledInputContainer>
+ return <StyledInputContainer error={error}>
           <input />
           <StyledClearButton>X</StyledClearButton> 
         </StyledInputContainer>
}

Until now it was pretty common development path for styled-components adoption. But here is the tricky part. In a very different module we want to have a TextArea component, which will have same border, border-radius (background color, hover/active states, etc.) as our Input. But it shouldn't have ClearButton. So the question is - how to exploit what is reusable here?
Answer is simple - put common part to the function and use it to populate different styled wrappers. We can do it first for the Input

const StyledClearButton = styled.button`
   visibility: hidden;
   // other styles for button
`

+ export const getCommonInputStyles = (props, closeButtonCmp) => css`
+   border: 1px solid ${props.error ? 'red' : 'black'};
+   border-radius: 4px;
+   ${closeButtonCmp && css`
+     &:hover {                     
+       ${closeButtonCmp} {
+         visibility: visible;
+       }
+     }
+   `}
+ `

const StyledInputContainer = styled.div`
-  border: 1px solid ${props.error ? 'red' : 'black'};
-  border-radius: 4px;
   display: flex;

-  &:hover {                     
-   ${StyledClearButton} {
-     visibility: visible;
-   }
- }
+  ${props => getCommonInputStyles(props, StyledClearButton)}
`

const Input = () => {
 // error state is handled here
 return <StyledInputContainer>
 return <StyledInputContainer error={error}>
           <input />
           <StyledClearButton>X</StyledClearButton> 
         </StyledInputContainer>
}

And now we can use extracted styles in whatever else component we want. Like mentioned above TextArea

const StyledTextAreaContainer = styled.div`
  ${props => getCommonInputStyles(props)}
`

const TextArea = () => {
 // error state is handled here
 return <StyledTextAreaContainer error={error}>
           <textarea />
         </StyledTextAreaContainer>
}

You can see that since TextArea doesn't contain clear button we passing it to getCommonInputStyles

That's it. I hope you'll find it useful in your daily work with such great library as styled-components

Testing events attached to HTML Document

Andrii Miroshnychenko — Sun, 21 Aug 2022 11:22:14 +0000

Component

Recently I was working on tests for one of our React components, which implements dropdown functionality. With appropriate prop enabled, it allows dropdown items to be collapsed on "outside" (anywhere on the page) click. Code for this part was similar to

useEffect(() => {
  const onOutsideClick = () => setIsOpen(false)

  document.addEventListener("click", onOutsideClick)

  return () => {
    document.removeEventListener("click", onOutsideClick)
  }
}, [])

As you can see, event listener is attached directly to document object, which is a reference to HTML Document. It is not a DOM node, which is important. Overall, addition of event listener to document is a wide used practice when you want to ensure your callback be fired on any place on the page.

Test setup

We are using React Testing Library to test our components. It encourages to work with components/features as user would've work with them. As a consequence, it's better to avoid doing things which aren't natural to your app user flow.
~~Unfortunately while dealing with document it's necessary to break this rule.~~ Main (and only) RTL's method of rendering test markup is render which build whole tree starting from dedicated DOM node, document.body by default.


render(<AppComponent />)
// Which equals to
render(<AppComponent/>, { baseElement: document.body })

// Code below won't work because document isn't a node
render(<AppComponent/>, { baseElement: document })

You can alter it by adjusting baseElement option of render method, but still it has to be DOM node. It's not possible to build a tree on top of document object itself.
This means opened dropdown won't be closed on click, because document object isn't simulated by testing library and no events will be issued.

Solution

First idea that I was thinking of was to hide dropdown by clicking on its anchor (our implementation allows to do so).

    // Initially options are not mounted in the tree
    expect(getByText('Option three').not.toBeInTheDocument()
    // This is dropdown anchor, click on it shows options to choose from
    fireEvent.click(getByText('Selected: Option one'))
    // Third option is now visible (and mounted)
    expect(getByText('Option three').toBeVisible()
    // "Technical" click, which won't be conducted by user under normal circumstances
    fireEvent.click(getByText('Selected: Option one'))
    // Third option is now unmounted again
    expect(getByText('Option three').not.toBeInTheDocument()

Despite being a working solution, this adds some unnatural flow to test and can potentially influence dropdown state in unpredictable manner.

Most preferable workaround (from those left on the table) is to simulate click event on the document object. This will cause callbacks to be triggered and won't require any additional user-related actions.

    // Initially options are not mounted in the tree
    expect(getByText('Option three').not.toBeInTheDocument()
    // This is dropdown anchor, click on it shows options to choose from
    fireEvent.click(getByText('Selected: Option one'))
    // Third option is now visible (and mounted)
    expect(getByText('Option three').toBeVisible()
    act(() => {
      // Direct call on document API
      document.dispatchEvent(new Event('click'))
    })
    // Third option is now unmounted again
    expect(getByText('Option three').not.toBeInTheDocument()

I hope this small investigation will help you in your daily work with RTL :)