Components and concerns

Here’s @adactio on components and concerns: adactio.com/journal/14103

“Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?” - @adactio adactio.com/journal/14103

adactio.com/journal/14103

the new function-based separation of concerns in the “component age” doesn’t mean we have to mix structure, presentation and behaviour. use the best of both worlds! 👌 via @adactio adactio.com/journal/14103

@adactio, would you mind if I translate your post adactio.com/journal/14103 for Russian-speaking web devs community?

“There’s nothing in [..] separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages [..] I would say it works best when it’s applied on smaller scales.”adactio.com/journal/14103 I always thought SOC makes the most sense on a component level.

Totally agree with @adactio on this one: Seperating by concerns and by components are NOT mutually exclusive. Quite the opposite in fact. Or, to put it another way, developing modular UI components is NOT an excuse to avoid seperating concerns.adactio.com/journal/14103

“Separating structure, presentation, and behaviour is a good idea. Separating an interface into components is a good idea.”—adactio.com/journal/14103 Guess who already did both — GOV.UK Design System, that’s who:design-system.service.gov.uk

Found myself nodding along in agreement with @adactio’s Components and concerns article: adactio.com/journal/14103 I’m particularly fond of his concluding paragraph which made both chuckle and hunger at the same time.

I agree with @adactio: nothing about component-based design is at odds with designing for a separation of concerns. adactio.com/journal/14103

“There’s nothing in the “traditonal” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages. In fact, I would say it works best when it’s applied on smaller scales.” adactio.com/journal/14103

Da hat Jeremy Keith mal wieder Recht: adactio.com/journal/14103

Very sensible thoughts (as usual) by @adactio on Components and Separating concerns > buff.ly/2KYmaCk

Separate structure from presentation or use components to separate by function? @adactio says ‘Why not both?” ow.ly/bdrL30kVdIA

Adactio: Journal—Components and concerns adactio.com/journal/14103

Excellent read on “Separation of Concerns” in a component based development approach. ⚡️ The different layers of #HTML #CSS and #javascript can be seperated in components as well and it’s the right thing to do! 🏖️ adactio.com/journal/14103

‘There’s nothing in the “traditional” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages.’ adactio.com/journal/14103

💯 “Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?” adactio.com/journal/14103

adactio.com/journal/14103

“Adactio: Journal—Components and concerns” It’s often the case that things presented as opposite and incompatible actually aren’t. Sometimes you can do both. adactio.com/journal/14103

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!