I’m in the middle of a quandary here, and I am not certain there’s a “right answer”, or if there is one I’m not sure I want to know what it is.

Despite years of web development, there are many technologies that I do not have a firm grasp of, and one of those is cascading style-sheets or CSS. I enjoy development, but I prefer making applications work; my ability to make them look good has never been strong but since I don’t have someone I can work with whose strengths can pick up my slack, I’m doomed to shove my way through technologies which make my products look at least passable.

Over time, though, I’ve started to fill in the knowledge gaps, and when I switched to using React for my front end needs I started using a library called styled components. Styled components are a way of encapsulating CSS into an element’s description, not unlike “inline CSS”, but also very much unlike inline CSS. When written as a distinct element, a styled component can be re-used anywhere in a project without having to apply CSS classes to a vanilla HTML element. Should it come to updating a component’s visual style, working on the definition of the component would be enough to change every instance of it throughout the site, so it’s also not unlike CSS centralized in a style-sheet. Here’s a quick example:

import styled from 'styled-components';

const MyTextbox= styled.input.attrs({
   type: 'text'
})'
   width: 100px;
   height: 30px;
   border: 1px solid blue;
   outline: none;
   font-size: 0.9rem;
   font-weight: 500;
'

const MyComponent = (props) =>{
   return (
      <MyTextbox name='firstName' value={formVals.firstName} placeholder='First name' />
   )
}

This is a completely crap example, but it shows that we can take an established HTML element (or even a custom React component), apply some CSS to it, and alias the whole thing so we can use it as if it were a native component. I’ve used this system to great effect in a few projects by creating form items with style and functionality as their own components and subbing them in for the traditional input, button, or select elements. The only downside is that it’s not always easy to tell what kind of base component the alias is referencing unless the alias is named along the lines of it’s ancestor; the above item would be better named something like StyledTextInput so other developers (or more likely my future self) will understand what they are looking at.

As convenient as styled components are, I find myself running into an issue: do I rely almost entirely on this library for my visuals, do I fall back on traditional style-sheets, or do I come up with some hybrid, and if I go the hybrid route, where do I draw the line?

In a personal project I am working on right now I have come up with some pretty complex interfaces. By using styled components and viciously abusing flexbox, I have been able to create styled elements that give me exactly what I want.

The issue is that this one popup is 300 lines of code. 156 lines of that is just defining each styled component that takes the place of more traditional div or other block elements. Of course, everything is exactly where I want it to be, the way I want it to be, so I’m not mad per se, but I am concerned that in the case of complex layouts like this one above, every single element becomes a styled component.

On the other hand, what would be involved in switching back to pure CSS…and why? I could excise the styles from the component file into a central style sheet, of course, reducing the size of the component. My layout would revert to POHTML adorned with classes, but therein lies the rub: I’d still need the CSS that I need to make this layout happen. Aside from common styles such as setting up frequently used flexbox definitions, there would still be a whole lot of custom, very specific and very targeted classes that only benefit this specific layout. Would it be more advantageous to create targeted style sheets, putting all of the classes needed for this one popup in a popup-specific CSS file? At that point what would be the difference between incorporating the styles into styled components and sequestering class definitions in targeted style sheets?

One thing I have yet to do is to pull the layout apart, and that alone might calm my britches enough for this to become a non-issue. As the above image represents a mockup, first-pass, or plain old proof of concept, I didn’t spend a lot of time trying to get it right from the get go like I normally do. The cover image and banner image sections will need drag-and-drop functionality as well as file browsing functionality in addition to styling, so those must become their own components. I could carve out each form element into its own styled component as is the intent of styled components in the first place. The author profile box would be it’s own thing as I expect to reuse it throughout the site. In the end, the single component layout of almost 300 lines of code should eventually get parred down to at least 1/4 of that or more, minus any functionality I have not yet even considered to make the form actually work.

Obviously this could be a “me” problem, and since I don’t normally start with a coded mock up all of my concerns might be strictly due to the inherent unease of seeing that much code in one single place.