Reconciling React and CSS

A key benefit of React is the potential of reduced cost through component-based development. Intuitively, the idea of components (in general) resonates with most engineers; sadly, with software components, theoretical advantages can be hard to achieve, unless you’re willing to spend more time and energy than might be expected.

In theory, components can prevent you from reinventing the wheel: you build a system by snapping together pre-written components like Lego blocks. But achieving this engineering nirvana can be much harder than it appears.

One fly in the ointment has to do with layout, which I refer to as the problem of CSS. Online postings regarding React and layout standards are all over the place, and there are some extreme approaches proposed, such as eliminating CSS entirely and embedding hard-coded style specifications into the components themselves. To anyone doing this, please understand that I admire your courage and determination, but my problem with this approach is that it is very difficult to reconcile with big CSS/SASS packages like Bootstrap. Unless you’re willing to move heaven and earth (and you have deep pockets), you’re going to have to come up with some strong standards for how components work in the context of an off-the-shelf CSS framework like Bootstrap.

Let’s assume you choose Bootstrap for a project. I strongly recommend that you have your components supply sensible default Bootstrap CSS classes, such that layout issues are handled automatically when your components are used in typical ways. For example, consider the Bootstrap modal, which is technically comprised of a chunk of HTML with some fancy Bootstrap CSS classes that enable the modal to appear to float over the top of the HTML page. This appearance and layout behavior requires the modal to have a variety of Bootstrap CSS classes declared at several levels in the HTML page. Thus, when you create a React component that declaring a modal, it would be best if your component supplied mandatory Bootstrap CSS implicitly. This way, the developer can use your modal component without having to read the Bootstrap online documentation, and without fiddling with the Bootstrap CSS classes.

This concept is worth repeating: if you (as the component developer) are willing to confront layout issues head-on, you will reduce downstream costs, and you will realize the benefits of component-based development. This brazen statement is based on my view that, today, the most costly part of full-stack development is dealing with layout and UX/UI issues.*

Some may argue that having components implicitly declare CSS classes is an anti-pattern, because it anticipates that those components will be used in a very specific ways. This statement is true: the moment that your components declare CSS classes, you are making your framework opinionated. Your components will assume that they are going to be used in certain ways, and declare default CSS classes according to the most common usage patterns. However, your components can also provide a "safety net" to allow the developer to override default CSS classes when necessary.

Thankfully, React has a great way to do this: component properties.

In VXFrame, virtually all components declare reasonable default CSS classes, but also expose component properties to allow the developer to override or augment those defaults. In most cases, developers can accept the default classes (and their respective layout and behaviors), and in corner cases, supply additional CSS classes to modify layout and appearance as needed.

*Later I'll write an article to back up my assertion, stay tuned.