As mentioned here, here, and here - we’ve been spending a lot of time building Reactjs front-ends that talk to decoupled back-ends. And if it isn’t obvious, we really dig it! Not only is it fun to develop in, the flexibility and control it can offer is so liberating that we simply must bring up the topic again. Here are a few of our favorite aspects of this lovely lifestyle.
Components in Reactjs Make Changes Simpler
Here’s a real life scenario for you. We’re building a cool tool for editing site layout that involves rows, columns, and blocks - all React-side. Originally, I had thought that editing the settings form for a particular layer would be best as a pop-up, but it felt a little disjointed. I decided it would be a better user experience if the settings form revealed itself within the section being edited. Trying something like that when the CMS is completely driving your front-end rendering probably means editing code in a whole bunch of places to get that to work and in some cases, it may be impossible. How long did it take me to change that approach in the React layer? About 15 minutes. Why? With Reactjs in charge of the front-end everything is a component, so taking this complex form and injecting it into a completely different place was super easy. And saving the form or even reloading it is all self contained in the component so it can travel anywhere and still do its job. Neato!
Form and Functionality Living Independently
Staying in the realm of forms - and specifically form widgets - you’ll often find that deciding how to set up something as simple as a field on a content type is a pretty important decision. It can be a lot of work to even make simple changes and altering an existing field is often not possible when a field is already populated. Recently, we had the need for a Media library but the requirements were still a little too fuzzy to make a firm decision about what it could support. Do they need categorization? Do they want their media files stored in the CMS or somewhere like S3? It can be difficult to know what to build when the CMS field type choice is typically tied to what kind of widget you want to display.
So, what did we do? We made the field within the back-end CMS (Drupal in this case) a Media type field and then just built web services to update or fetch these entities and the separately picked a front-end approach we liked for selecting and uploading. Where this gets really great is that if it turns out we want something different for the widget UI, we can swap it with other React components and continue to use the same web services for management. If we like the UI but maybe need a little different storage model, then we can swap the web service logic out and continue to use the front-end widget to connect with it. So, what this means is that you can move forward, “for now”, knowing that any change in future requirements doesn’t necessarily mean rebuilding the whole thing and instead just tackling the parts you want to change while leaving the parts you like. Amazing!
Finally Achieve the Standardization We All Want
Another common problem with websites managed entirely by the CMS - front-end and back-end - is that it is often hard to standardize the aesthetic and user experience. For example, you might have a right rail on your blog pages that contains a widget for showing a tag cloud of all tags on that blog article. Let’s say then that you now really want to show a “Most Popular” tag cloud in an area of your homepage and you want it to look and behave exactly the same. Easy, right? Well, in the first case it’s possible you used a CMS plugin that generates such a UI component and it’s tied contextually to a specific page, or perhaps you are passing arguments into a twig template for all blogs, or perhaps it’s a dynamic view of data that you are applying custom CSS to. The homepage, however, might be completely rendered by dynamic blocks, or by its own custom template, or some other means. So, now what you have is the prospect that doing something as routine as making two site components look and act alike is unexpectedly tedious and/or expensive because the two use cases are rendered very differently by the CMS. Well, this is not at all the case with something like React driving the front-end. In this world, you just need to build your tag cloud component with its appropriate data properties and methods - and then use it in both places, passing in the data to the component from each disparate data source. And just like that - you have an identical aesthetic and UI driven from very different parts of the site. Astounding!
So, there you have it. Just a few more of the many many ways our life with Reactjs is breaking the chains and opening the door to new possibilities and providing more flexible and deliberate experiences for our clients and the users of their sites.
And we’re having a heck of a lot of fun at work!