When the Content Just HAS To Appear
You don’t always choose your content scenarios—sometimes they choose you.
Wegmans came to us with a predicament: they had developed a brilliant recommendation system that suggests recipes based on your shopping history. We had helped get these recipes to display on their site’s homepage, but as you might guess, the most important time for shoppers to see relevant recipes is just-in-time—when cracking open the Wegmans app in-store before this week’s haul.
At first glance, this seemed like a straightforward task. The recommendations are requested by some in-page JavaScript, brewed on-the-fly, and then piped onto the page’s HTML. While the official app is HTML-and-JavaScript-based, it exists in a separate system with its own development cycle that would have made rapid iteration and style consistency between site and app more difficult.
What we needed to do was create a self-inflating version of these recipe components that would allow them to appear anywhere there is JavaScript access, including places we didn’t have control over the server-side markup or CSS. This certainly sounded like a job for a JavaScript framework.
While React is certainly the frontend community’s collective darling, it can be a little too Swiss-army-knife for smaller projects. Vue, a fast-growing underdog, has taken some of the concepts that make React great and packaged it into a more lightweight and succinct package. For this focused purpose—standalone widgets that can be embedded everywhere—it was a perfect fit.
We split apart the pieces of the UI into self-contained Vue components that can be entirely customized through the data and variables passed to it, including goodies like randomizing recipe order and applying background flair. To keep things consistent with the website, we also wired these components into Wegmans’ WordPress admin interface.
OK, so we have these Vue components, but they come with some baggage: custom CSS, third-party JS (like the Swiper slider library), and other odds-and-ends like icon fonts. Because the app would be loading our code on top of its own resources, adding all of these things in independent <script> and <link> tags like it’s 1999 would introduce a ton of extra network requests and lag.
Enter Webpack. While it describes itself as a module bundler, a wordier but more accurate description would be “Just about any type of web file translator, compressor, packager and loader” (Should I be on their branding team?).
With a well-tuned Webpack config, we were able to compress and tie together widgets and their assets into the same few files, even siphoning off some shared styles from the main website. With Webpack’s lazy loading feature, we could also ensure we only loaded widgets that were needed on a given page.
At this point, we were proud of our solution, whose name we couldn’t resist alliterating to “WegWidgets”. But we also wanted to make sure that it was easy to use. So as a final step, we wrapped all WegWidgets functionality in an API for Wegmans to use. In the full documentation we wrote up, we describe how you can specify which widgets you want, where you want them, what they should display, then paste a tiny embed code afterwards, and voilà—styled, interactive content inserted into Wegmans’ app—or anywhere else on the web you want to use it!
And since we built this into an existing build and deploy process, future improvements to widgets or even entirely new ones can be added to the app and website simultaneously with very little ado. We were able to turn a difficult content and branding scenario into an opportunity to develop and share components across different mediums!