Working Towards Ui Components
16th Jun 2014
There is a lot of talk about components in the UI space. I’m currently working with Econsultancy on building a library of components for use in their website. Just to be clear, I’m not talking about the WebComponents spec here.
A bit of history
I first started experimenting with the concept of components when I built the Lloyd’s of London website back in 2009. I designed the concept of
layouts which could specify nested elements and could have slight variations which I called types.
The tough part to building components on the web has always been a way of managing modular blocks of code and their dependencies. In recent years a few advancements have become widely used to make this much easier.
Then the BEM definition became widely popular defining blocks, elements and modifiers and allowing a syntax which was commonly known to help keep CSS modular.
The Last Stronghold
But why is this important?
There are a couple of key reasons I’m battling with this.
Secondly, to be able to properly separate concerns of a component (being HTML/CSS/JS) and it’s inclusion in to a website we need to be able to build them in isolation. This often means that the front-end developers are using Node.js to maintain a catalog of these components.
I’m coming to the conclusion that ideally these catalog sites should just use the same server side language as the main website. It feels like a defeat to my ideal. I’m a firm believer that if you want the best out of someone, you allow them to use the tools which they are comfortable with. Then the tools don’t get in the way. However there seems to be so many hoops to jump through, created when different server technologies are in play. This doesn’t change the fact that we still need to be able to maintain templates that work for dynamic components in the browser … aghhh this feels like a total mess and I’ve almost resigned myself to maintaining 2 markup templates for each component. At least we can keep them in the same place and be maintained by the front-end developer not passed on to someone who isn’t specialised.
At least there’s a plan
Ok, so this leave’s me kind’a satisfied, that even if I can’t always have the ideal I would like to see these important things:
- The front-end developers are the ones who do the markup, everywhere
- We work with a set of components which can have moving parts (i.e. modifiers)
- We work through the restrictions for a long-term gain of good maintainability and valuable documentation