Sharing components between front-end and back-end
As a front-end developer there is nothing more annoying than losing the control of your HTML after your code has been implemented in the back-end. This typically happens when the HTML isn’t shared between front-end and back-end. But it‘s not the fault of a back-end developer. It‘s the fault of the front-end which failed to provide a good integration into the targeted CMS. Our mission at comwrap was to solve this problem.
The problem
Our existing workflow followed a pattern that allowed us to develop the front-end without caring too much about its later use. HTML, CSS and JS wasn’t tied to a specify CMS. Want to use a different templating engine? No problem, as long as the output (HTML) is the same as before.
The issue with this workflow was that both projects were disconnected. Changing HTML always required to update the implementation in the back-end, too. And that gets out of control as soon as you have to touch more than one line of HTML. You need to communicate every adjustment you’ve made and you need to check if everything has been changed accordingly. And no matter how good you are, spotting a different tag, class or attribute inside the reimplementation is almost impossible. All those little deficiencies quickly sum up to issues that are hard to debug. “It works fine in the front-end” or “I can’t reproduce it” are the resulting answers after a bug has been reported.
“It works fine in the front-end” — Every Front-End developer, always
The challenge
Each team had different preferences and we were looking for a solution that works great for both. In the front-end we preferred to stay with our existing front-end build process that is powered by Rosid. The back-end on the other hand already worked with a component system called Fractal and expected a similar interface and integration. Indeed, Fractal already had what we were looking for. It’s a UI that helps you to build and document components. We tried hard to integrate the system into our build-process, but we had to accept that Rosid and Fractal aren’t playing well together.
The concept of components
Fractal showed us what a solution could look like. It forces the developer of the front-end to write small, reusable components. The back-end then uses the same components and renders them with real data, instead of the dummy data used in the front-end. The components can later be assembled in a variety of ways to build anything from larger components right up to whole pages. This concept isn’t tied to Fractal or a UI in general, but the interface helps you assemble, preview and document those components in a visual way. Brad Frost calls this “atomic design”. I highly recommend the book he wrote to learn more about robust design systems.
The solution
Our research and the concept of Fractal showed us that we were actually looking for two things:
- Components: A way to share the same HTML between front-end and back-end. This requires a templating engine that works on both sides.
- UI: A way to visualize components. Great for the whole team as it makes communication easier when you can show what you are talking about.
We decided to use Twig as our templating engine as most developers were already familiar with it.
Finding a UI was way harder than finding a templating engine. In the end we made the step and developed our own system. After two projects we can say with certainty that this was the right move.
Malvid
Let me introduce you to Malvid, our own UI solution. A Node.js module powered by modern technologies, focused on components and rendered blazingly fast with React. We took everything that made Fractal great for us and tried to do it even better. A static site compiler that generates a web-app from a given folder structure of components.
Malvid shows all relevant information at a glance: Your components on the left and a preview, the template, data and notes of the selected component on the right.
Conclusion
Changing a workflow isn’t something that happens over night. It requires a lot of input from your teams, research and brainstorming. But don’t lose yourself in details! You will never know if it works before trying it and you can’t solve everything at once. Your new workflow might crack existing problems, but it also introduces new ones.
Sharing components between front-end and back-end was the right move for us. No matter if Fractal, Pattern Lab or Malvid—try to find a way that works for your company. The switch might be worth it.
