Thanks for sharing — seems like a good effort to address React component styling.

Thanks for sharing — seems like a good effort to address React component styling. It is just a beginning of my acquaintance with this library, but there are several things that it encourages that I think are bad for the code.

Imagine you have this Home Panel module:

<!–– html ––><div class='home-panel'><div class='header'><div class='header-main'><h1>Here is a home panel</h1><p>Welcome to this example!</p></div><div class='header-aside'><button>Read more</button><span>Some help text</span></div></div><div class='content'><div class='content-section'><!–– some content ––></div><div class='content-section'><!–– some content ––></div></div><div class='footer'><!–– some content ––></div></div>

header, header-main, header-aside, content, content-section andfooter classes all have some kind of css that gives them positioning and perhaps color and border.

Our Home Panel css code may be reusable, and smaller components like Main Button and Hint can also be reusable, but the other divs can’t be reused separately from their usage in Home Panel.

Normally I would write this React component in the following way (just giving classes to everything):

export default class HomePanel extends React.Component {render() {return (<div className='home-panel'><div className='header'><div className='header-main'><h1>Here is a home panel</h1><p>Welcome to this example!</p></div><div className='header-aside'><button className='main'>Read more</button><span className='hint'>Some help text</span></div></div><div className='content'><div className='content-section'>{ 'some content' }</div><div className='content-section'>{ 'some content' }</div></div><div className='footer'>{ 'some content' }</div></div>)}}

Styled Components way is to create components. So, the above code can look like this:

export default class HomePanel extends React.Component {render() {return (<HomePanel><HomePanelHeader><HomePanelHeaderMain><HomePanelTitle>Here is a home panel</HomePanelTitle><HomePanelSubtitle>Welcome to this example!</HomePanelSubtitle></HomePanelHeaderMain><HomePanelHeaderAside><MainButton>Read more</MainButton><Hint>Some help text</Hint></HomePanelHeaderAside></HomePanelHeader><HomePanelContent><HomePanelContentSection>{ 'some content' }</HomePanelContentSection><HomePanelContentSection>{ 'some content' }</HomePanelContentSection></HomePanelContent><HomePanelFooter>{ 'some content' }</HomePanelFooter></HomePanel>)}}

It could look like like that, but I get it that you probably won’t ‘componentize’ each div that has styling and will reserve Styled Components for smaller reusable things like inputs, buttons, etc.

If you did ‘componentize’ each div like the above, that would quickly become a huge overhead. Also, the inner divs are not separately reusable, so you don’t win much by extracting them in components.

So, let’s say you make components where it makes sense, and use classes otherwise. What we end up with is code that contains both classes and Styled Components. Which leads us to the first problem:

1. Your css code is now in two places — css assets and javascript assets.

What this means:

• Debugging CSS is harder
• Maintaining CSS is harder

Second problem is the reason I cannot use this library at my company.

It is common to use more than one front-end framework within an app.

It is also common to have html templates and React code both used within one app:

2. Styled Components depend on React implementation. CSS defined there is not reusable outside of your React code.

What this means:

• Adds coupling between styles and markup implementation
• Doesn’t make sense if React is just a part of your overall app

But more importantly, it ties your css code to React. If 3 months from now, you want to launch a new page using an html template, you’ll have the overhead of re-implementing CSS that you thought was already there.

Styled Components library certainly may have some good uses, and it is great to see a different approach, but it is bad for separation of concerns and increases potential maintenance overhead. A pattern is better than no pattern, but this is probably not the one I would recommend.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!