How we built a next-gen car configurator for Mazda using Meteor and React
By Rahul Choudhury & Laurens van den Oever
This is a guest post by Rahul Choudhury & Laurens van den Oever of Q42, a Dutch tech agency with offices in Mountain View, The Hague and Amsterdam. Q42 is an Official Meteor Partner.
You already know that we do jumpstarts at Q42. But did you know we regularly use Meteor in production with large clients? Let’s talk about one we recently completed: Mazda’s new Car Configurator. Matt Debergalis even mentioned it in his last Meteor Night talk about Meteor 1.3!
Today, most car configurators are complex little things often built with the technology of yesteryear. Lots of screens, buttons, jargon and, well, configuration to deal with. Car manufacturers seem to design them from their own point of view, so the end result is often accurate but not so easy to use. As a result, making your way through the default options is relatively painless, but if you want to do more, and really dive into customising your ride, it gets complicated fast. Because we thought we could do a better job, we teamed up with Dutch strategic design agency Oak & Morrow and Mazda Netherlands to build a much more user-friendly car configurator.
This configurator is the first to combine a static marketing website (including all the beautiful pictures and detailed descriptions) with the variety of technical factory options you can choose from. In fact, the whole site is a configurator, instead of one little component on a static website.
We wanted to build a very flexible website that would be easy for all kinds of people to use. On the one hand, since it’s a configurator, we knew it would include a lot of widgets, sliders and buttons that you’d use to change your selection, similar to a web app. But just building a web app wouldn’t be enough, as we also wanted to include the kind of persuasive photos and rich content you’d expect from a marketing site. Combining the best of both worlds proved quite challenging on the project, technical and interaction design level. So what platform do you choose when there’s limited time and such a large scope? Meteor of course. It allows you to spend more time on building new features and functionality for the customer and less on technical issues, since it’s designed to solve a lot for you. As a result, while this kind of car configurator invites quite a few technical challenges, we managed to tackle them all with Meteor, React and one crucial package we built.
React and Meteor
Today Meteor’s React integration is great, especially since Meteor 1.3. But when we started this project midway through 2015 when Meteor 1.1 was the latest release, it was still relatively unexplored territory, so it was a bit risky and quite exciting.
The reason we initially decided to pick React was when we compared it with Blaze for the kind of app we wanted to create. React is designed from the ground up to work with interactive components, whereas Blaze is really more focused on getting something up and running quickly. Each way is fine, but our team wanted to go with React in this case because we knew that components would be a big feature.
Server-side rendering with Flow Router
A second reason to use React is because we wanted to render everything on the server. We decided to try Arunoda’s then-experimental Flow Router 3.0. Since we know Arunoda personally and he has a great reputation in the community of delivering working software, we were confident every possible issue would be fixable.
Client-side database
For this project we chose to ship the entire database to the client. This is a big anti-pattern in the Meteor community! But one of our goals was to create a super-responsive app that didn’t feel like a web app. So we wanted to be able to filter, select and access data on the fly without having to wait for the server. Optimistic UI combats this to some extent, but you just can’t get around the need to request a new dataset from the server and the associated cost of waiting at least a hundred milliseconds.
Performance challenges
One consequence of this decision was a drop of performance of the app on older mobile devices due to the way React handles view updates. React maintains a virtual DOM to quickly render updates and will call the render code for all components in a changed subtree assuming that is a cheap action. Unfortunately in the Mazda case, a small change in state can have many small changes in the UI all over the page.
An example is picking a new color. Obviously changing the color will update all exterior photos to match the new color. But the color may also come at a premium price, so the price of the current configuration should also update. And some colors may not be available on some models, so the UI for switching to those models should also update. All of these are quite subtle changes, but they affect the entire page. For all these changes, React will call the render code for the entire page, and that may take seconds on old devices. So we needed to come up with a way to only call the render code for components affected by the change. To address this, we designed a Meteor package called autovars.
Mazda @ Meteor NL meetup
We originally planned a detailed deep dive into this package, but at this point with Meteor and React’s 1.3 integration, as well as recent developments in the React community, it’s quite outdated!
Instead, we recommend watching the below talks. In January we hosted a Meteor meetup at our offices in the Hague to talk about our experiences building the Mazda Car Configurator. The team that worked on the app gave talks about what they worked on:
Choosing Meteor and React worked out really well for us despite some performance challenges. The results? Mazda NL saw their conversion rate go up by 60% in the months after we launched the car configurator. So mission accomplished!
