As you’ve been travelling around the internet soaking up all the knowledge you can on React and other front end technologies, I’m sure that you will have come across the term, componentised UI. If you thought “What is a componentised UI anyway?!” (or “What is a componentized UI anyway?!” if you are reading state-side) then I hope that that this week’s post answers that question for you.
Seeing in Components
Let’s dive right in and talk about what we actually mean by the term componentised UI. The basic concept is that the user interfaces you build should be composed of many components, which themselves will be composed of components and so forth until you have broken down the application into it’s most basic building blocks.
From there you are able to compose the UI you are building simply using different combinations of these building blocks. Potentially you could then use these same building blocks to compose other user interfaces within the same system as well and this is one of the benefits, which we’ll talk about later.
In my previous post this is exactly what we did. We refactored the Scroll Creator app that we’ve been building from being a single giant component into a componetised UI. During this post the first thing we identified was that the scroll component had a separate set of concerns from the form above it so we split that away. Then we split out the form and after that we split out the single text input controls and the special multi text input boxes into their own components as well.
If you are more of a “learn by doing” person you might even like to walk through the post linked above to get a more in depth look at how to implement the process we’ve just described above. For now though, to help you visualise it, here is what the application looks like. I’ve take the liberty of drawing pretty blue lines around all the things that we considered to be separate components which we then split up:
You can see that the application component, which is the outer blue box, is now composed of lots of smaller components some of which are components in their own right and some of which only exist to house other smaller components.What we have created here is a componentised UI.
After some time working with React you will get the hang of seeing a web page as the composition of components and when you start seeing things in these terms it becomes a lot easier to envisage how you might go about constructing your application in this way to solve real world problems.
Yeah, but why?
Why do we do this? To buy ourselves some “ilities”. The main benefits of a componentised UI are maintainability, reusability, readability and enhanced separation of concerns.
By breaking down our application into such small building blocks we gain a lot in maintainability. This is because when you build user interfaces in this way you get a certain degree of decoupling between components almost for free.
Take the above application for example. If we wanted to change how the scroll component displayed or perhaps add another component that used the same data as the scroll component then we could do this fairly simply. All we would have to do is write the new code for the component and build the relationship between this new component and it’s neighbours in the application and we’re done.
After that provided we haven’t modify the contracts by which any other components talk to each other then the changes we make should be entirely localised to the parts of the system which needed to be changed in order to build the new functionality and everything else should remain unchanged. I’m sure I don’t need to waste time selling you the benefits of this kind of encapsulation.
This decoupling has another upshot in that our components become ultimately resusable! You can see this in action in the app that we refactored above. In the app we were able to use the TextInput component for both the “Your Name” and “Their Name” fields of the form.
In theory we could also use that TextInput component anywhere else in our application that we wanted a labelled text input control. This means that with this control we can build more user interface for less code and effort.
We also gain a certain amount of confidence in these lower level components because we know that they are being used (and presumably working) in so many places throughout our application.
Another benefit is that by reusing components throughout your application you can begin to develop a user experience that your users can rely on. Particularly if you are using bespoke user controls then you’ll find it’s extremely valuable to have these look and act the same throughout the entire application.
We gain a lot of readability in that we now don’t have to explicitly write all the code necessary to display an entire component in the
render method. Instead we can describe, using components, what the component is composed of right there in the code.
This is provided, of course, we have good names for our components. But if you take care to give your components good names then a componentised UI in react can produce very readable JSX. Just from looking at the JSX you should be able to take a single component and quickly be able to discern what it does, what is made up of and how it interacts with both it’s parents and children.
This means that, in theory, for you to be able to reason about what a certain part of your application is doing you only need to understand the inner workings of the components involved in the part of the application you are looking at. As opposed to the alternative which is you potentially having to grok the entire application all at once which would most likely be the case if your application was composed of just a couple of larger components.
Separation of Concerns
Finally, componentised UIs also help us to be able to maintain a separation of concerns between our components. This is another thing that we, as developers, can agree is almost always a good thing. It ultimately means that each piece of the application has only one reason to change which means that less of our application needs to change any time we need to modify our application.
So, why all the components all of sudden?
So how did we get here to the point we find ourselves now. It seems we have an abundance of bearded flannel wearing developers raving about componentised user interfaces now but we’re all sure this wasn’t always the case, so what happened?
It’s is my belief that the evolution of the front end towards componentised UI’s has been facilitated by the evolution of the stacks we use to build web applications. Even if you don’t wholly agree with this sentiment there is probably, at least, one thing we can agree on; a big factor as to why a componentised user interface is so attractive in modern development is because it is a paradigm that closely aligns itself with the idea that the smaller chunks you break a big problem into the easier time you’ll have writing good software.
This idea has been popular in development for a fair while now but it seems that with each passing year, new piece of technology or latest architecture more developers are striving to achieve this granularity in all aspects of development.
The front end of a modern web application has very much grown to be a first class citizen in the development stack today. Rather than simply an after thought of an engineer who just got done putting all the business logic in the code-behind of another aspx page. As a result of all this attention very clever people are starting to apply very clever patterns and principles when developing these front ends and we’re all reaping the benefits!
Sure the service oriented architecture turned out to be just way to turn one monolithic system into a few still really big systems, but the good news is that from those ashes came rose the Microservices Phoenix! The Microservices revolution has been helping developers solidify the notion that “small things good, big things bad” and it gets stronger with each thing they make tinier and tinier and simpler and simpler. Developers have now started wondering what other things can benefit from this approach and this thinking certainly would have helped develop the concept of the componentised UI we know of today.
So, my point is, I believe that a combination of back end architecture going the way it has and the promotion of front end development as a development discipline in it’s own right has really done a lot to make componentised UIs so attractive to modern web developers.
We’re stronger together
Congratulations, you now know what a componentised UI is, why they have become so popular and why all the cool kids are building them. You’ll find as you delve into React that the community really is full of very talented people all of whom are trying to help each other build better and more effective apps than the ones they built yesterday. In fact there are so many cool kids are helping each other out in the React-sphere that a number of patterns and technologies have sprung up around facilitating the ability to build robust and scalable user interfaces using React.
These targeted domain specific patterns are very powerful and definitely worth a look in. The most notable of these is Flux which is a architectural pattern focused on helping to build more decoupled components which are able to operate in very predictable ways are easy to reason about.
One of the more popular implementations of this pattern is Redux. I hope to do a post on Flux and another on Redux sometime in the near future so keep an eye out for them! In the mean time you might just like to check out their websites if you’re interested in learning more.
So now that you’ve shovelled all that knowledge into your brain you are now ready to impress your family, friends and coworkers with your amazing ability to split big things into smaller things and then build big things out of those smaller things again.
Don’t be afraid to stop by and leave a comment on here or any of the social medias and let me know how impressed they were! Until next week, have fun developing!