It’s funny how patterns and styles get recycled. We’ve seen clothing styles of the 60’s get reintroduced and reused decades later. The TV show Mad Men brought back mid century modern style into the 2000s. And we’ve seen it happen with coding patterns as well.

React Components

One of the first React things I learned is how to create React Components, Capital-C.

export default function NavButton() {
	return(
		<button type="button">Switch Step</button>
	)
}

To use this button, just import it into other files and apply it in the JSX. Straightforward.

Props == HTML Attributes

Buttons usually need to do things, so let’s give this some interactivity.

function NavButton(props) {
	const { transitionCallback, isDisabled } = props

	const handleClick = () => {
		transitionCallback()
	}

	return(
		<button
			onClick={handleClick}
			disabled={isDisabled}
		>
			Switch Step
		</button>
	)
}

2000s me looked at this increasingly used React pattern curiously, because I see onClick={handleClick} attached to the button element. For so many years, often from jQuery or Javascript, I avoided applying event handlers to elements. But here React made that a pattern and my mind goes back in time.

My concerns are separate

I spent the 2000s and into the 2010s learning about, what I eventually started reading from industry folks and books, a computer science term called Separation of Concerns. The idea makes sense on the front-end for many reasons and I became fairly dogmatic about it.

With Separation of Concerns, these three concepts stand on their own:

  • structure (HTML)
  • presentation (CSS)
  • behavior (JS)

By the middle of the 2010s, I wasn’t mixing JS and CSS into HTML, CSS into JS or HTML into JS. We keep them separate, .html, .css, and .js.

By contrast and in practice, however, having worked with WordPress all that time, it was often a losing battle to decouple these languages, quick jQuery or CSS fixes were little inline sprinkles here and there. 

<?php
function ratio_calculator() {
    $html = '<style>
	.form-inline .form-group { display:block; margin-bottom: 10px}
</style>
<form id="form" name="form" method="GET" action="#" role="form" class="form-inline">
	<div class="form-group">	
		<label for="RT3" class="t3">RT3</label>
		<input class="form-control" type="text" name="RT3" id="RT3">
	</div>
    <input type="button" class="btn btn-primary" name="button" id="Submit" value="Get Ratio">
</form>
<div id="ratio" style="color:blue;font-weight:bold;font-size:120%"></div>';
return $html;
}
add_shortcode('calculator','calculator_form');

Yuck! I had to grit my teeth and move on.

Then came modern JS frameworks, cemented by React, slowly blowing this concept up. React’s raw JSX syntax requires to cross the decoupling line by adding HTML-like attributes called props containing Javascript and often CSS. A different and controversial method called CSS-in-JS is not only accepted but widely adopted by many React developers. And then there’s the other CSS direction of using utility first libraries like Tailwinds polluting HTML classes, but don’t get me started on that concept!

Separation of Concerns Remixed

In this new paradigm of component-first development, the abstraction for separation of concerns takes on a different look. The separation of concerns is loosely defined within the components themselves. Let’s take a look at what this means.

Here’s my first iteration of the navigation button control component to go from the initial state to the timer state.

function NavButton(props) {
	const { transitionCallback, isDisabled } = props

	const handleClick = () => {
		transitionCallback()
	}

	return(
		<button
			style={{padding:'1rem', backgroundColor:'white'}}
			onClick={handleClick}
			disabled={isDisabled}
		>
			<span className="visuallyhidden">Switch Step</span>
			test
		</button>
	)
}

This code shows a clear mix of all three languages within a Javascript function, with an HTML-like syntax inside of a Javascript return statement, inline CSS in a button element, and an inline onClick event handler calling a function.

Before I started learning how to make websites, the source code of the web documents used similar syntax that kind of looked like the above.

<head>
	<script type="javascript">
		function handleClick() { 
			var transitionCallback = props;
			transitionCallback(); 
		}
	</script>
</head>
<body>
		<input
			align="left"
			clear="left"
			bgcolor="white"
			type="submit"
			onClick="handleClick();"
			disabled="disabled"
			value="test"
		>
</body>

When I first saw React’s syntax, you can imagine how alarmed I was by its seemingly reversion back to the 1990s styling of code. My mental model is so conditioned that this bothered me for a long time, still does to some degree.

Two what end?

As I see modern libraries continue these practices, it appears the pattern of everything inside of JS will continue into the foreseeable future, one way or another. Discussions around native Web Components in the document brings a more dogmatic potential back, but not in its current iteration.

I’m always excited for the future, but I think there will always be a part of me looking of ways to scale back the abstractions and packages needed to build the modern web. Part of that will be my outdated mental model for separation of concerns. Let’s hope browser makers can find better ways to manipulate the DOM and CSSOM without breaking the clients and mixing our concerns!