Creating dynamic, reactive UIs for Shopify without React

pbj — Mon, 19 Nov 2018 14:44:30 +0000

There are a ton of sites on the internet which rely upon Shopify to power their e-commerce needs. Almost all of those websites have interactions which are responsible for a handful of UI-based updates. Managing those UI updates between various JavaScript files can sometimes get carried away, leading to unorganized or closely-coupled code.

The most recent site I built, Colugo, uses Shopify and I ran into this thought while planning the build. I knew I’d need to share component state(s) between components and the site overall. I considered adding React but then decided to use the publisher-subscriber pattern via an events library may be a simpler approach. And as most clickbait articles would say: The results will shock you!

Using Events in Shopify

It came to my surprise when I found out Shopify has an events library pre-packaged within Slate. By way of Webpack, Shopify ships with an event module, “events.js”, which implements the Node.js events module for browser environments.

This approach can be achieved with any other events module as well.

Dynamic, Reactive User Interfaces

My goal while building the e-commerce site for Colugo was to reduce direct coupling between my components as much as possible. Using a publisher-subscriber pattern to manage events made decoupling a breeze and ended with a much more organized code base.

Knowing I’d use this pattern up front enabled me to map out a few components which would require dynamic UI components and what some states would look like:

When a user adds an item to the cart
- If successful, display the minicart and/or confirmation message
- If unsuccessful, display error messaging.
When a user clicks the mobile “cart” icon to display the menu
- If the mobile menu is visible, close it and display the mini cart
- If the mobile menu is not visible, open the mini cart.
When a user views the product detail page
- If a user selects a product color, then scrolls:
  - Display current color selection
  - User may update selection
  - New selection reflected between shared components
- If a user updates color selection:
  - Display current quantity
  - When a user scrolls back up, new quantity should correctly display between shared components

If we were using React, a lot of this UI interaction would be composed via Redux or a HOC passing props and event handlers to smaller components. Since we can’t easily use React with Shopify we needed another way to share small pieces “state” updates between components.

Enter Event.js

Using Namespaces For Organized Events

Because our events were being fired in more than one module, we created a small object which exposed the event “types”. It looks like this:

export default eventTypes = {
    menuUpdate: 'colugo:menu-update',
    mobileMenuUpdate: 'colugo:mobile-nav-update',
    cartUpdate: 'colugo:cart-update',
    variantUpdate: 'colugo:variant-update',
    productNavUpdate: 'colugo:pn-udpate',
    miniCartUpdate: 'colugo:minicart-update',
    recircUpdate: 'colugo:recirc-update',
    recircCartUpdate: 'colugo:recirc-cart-add',
};

This module isn’t special. It provides a consistent way to set up named event publications and subscriptions I know won’t collide within modules.

Payloads

Within each event, we passed in a payload object which represents the data any and all subscribers could use to update their UI. In the case of Colugo, the payloads were usually:

Product
- Variant
  - ID
  - Title
  - Price
  - Inventory
  - Color
Cart
- Total Count
- Items Array
- Cart Update (Success or Failure)
Display States
- Mini Cart Toggling
- Menu Toggling
- Newsletter Modals

Publishing Events

Now that we have our namespaces setup along with our payloads, we can publish an event:

import events from 'events'
import eventTypes from 'eventTypes'

events.emit(eventTypes.variantUpdate, {
    ... payload object
});

Subscribing To Events

Our event bus now makes subscribing events super easy. Bringing together our namespace and payload, subscribing to events looks like this:

import events from 'events'
import eventTypes from 'eventTypes'

events.on(eventTypes.variantUpdate, (payload) => {
    ... run whatever you want
}));

This separates UI updates from the events themselves. For instance, within Colugo, when a user selects a different product color a few UI changes happen:

New color is selected as active
Product variant name is updated
Product price is updated
Product inventory may be updated
Product gallery images may be updated.

In past projects, I may have written all the UI changes into one “products.js” file encapsulating all of those DOM elements which make up the UI which changes. While this worked, we also had to keep track of multiple UI components, track which one was changed, when it changed and then propagate changes to other components. In a nutshell, the old approach meant a lot of arrays and looping.

In the case of Colugo, if a user interacted with the color picker, we subscribe to the variantUpdate event and call the component methods to update the UI.

import events from 'events'
import eventTypes from 'eventTypes'

events.on(eventTypes.variantUpdate, (product) => {
    // destructure object for props if necessary
    //
    colorPicker.setActiveColor(product.variant.color)
    productContent.udpateTitle(product.title)
    productContent.updatePrice(product.price)
    productContent.updateInveotyr(product.inventoryCount)
    productGallery.updateGallery(product.variant.images)
    ...
    ...
});

By leveraging the publisher-subscriber pattern and the built-in events library in Webpack we’re able to manage UI changes in a clean, consistent and organized manner. Our footprint is kept to a minimum and UI components (existing or newly made) can easily subscribe to events with very little overhead.

Aside on “events”

Throughout this article we use the term “events”. It’s worth clarifying we are not referring to browser events like “click” or “onchange” event. With the publisher-subscriber pattern, there are no browser events being fired so it can be beneficial for performance as well.

Helpful reference for further reading:https://stackoverflow.com/questions/27677692/performance-cost-of-pubsub-excessive-events-and-event-handlers-in-javascript

IRL Examples

Rather than just talking about the work, feel free to check out Colugo's Product Detail Page and poke around! You’ll see how pieces of UI interact with one another. Here are a few areas you can look at which take advantage of the publisher-subscriber method and events.js

Select a color on a product page
- This should change the image gallery and some content in the hero
Scroll down and use the sticky color picker to update the color
- This will sync up the content and gallery to the new current selection
Add a product to the cart -If successful, will open the cart and update the cart number count

Demos

Pub/Sub - Counter Example

Pub/Sub - Cart Notification

Pub/Sub - Active Element

Big thanks to Zee Spencer for reviewing and editing this post before publishing.

Who Cares?

pbj — Mon, 18 Sep 2017 22:05:48 +0000

Does your app work with Vue.js even though all your friends are using React.js? If yes, then who cares.
Do you still get work without having a portfolio? If yes, then who cares?
Do you learn better from reading books instead of watching videos? If yes, then who cares?
Do you earn money by building sites with PHP instead of a Ruby (on Rails)? If yes, then who cares?
Did you just buy new running shoes right before the new All Birds released? If yes, who cares?
Did you learn JavaScript by way of jQuery? If yes, who cares?

This list could go on forever but you get the picture. The reality with our work, and our lives, is we all do things differently. Unless you’re doing something really wrong, who cares?

If your intentions are well-formed and your work is well-crafted all that matters is helping someone, or something, progress forward.

You may not work at the hottest startup or on the newest product. If you enjoy your life, work and everything in between then who cares about what others are doing? You don’t need to follow the "herd" to be happy. You can achieve your personal, professional and financial (or any other) goals by following your intuition, gut and common sense. You can be you and still be happy.

We could spend our days arguing over skeuomorphic design vs flat and the "resurgence" of brutalist sites but will it make our lives, our customers’ lives, or families’ lives better?

Sure, you can have an opinion, you can voice it, you can scream it from the tallest rooftops but here's the kicker, your opinion may not be someone’s fact. It isn’t a truth to be told and held over the heads of others in or outside our industry. Your way of doing something may be right for you and your organization, but it may wrong for a friend or another company.

Our peers are a good barometer for quality but we still must trust our gut to find the right fit, tool, direction. And ultimately, who cares if the decision you make goes directly against the herd as long as you’re happy and it’s positive for you without negatively impacting others.

Continue to be you, try new things and be open. If you pause because of what other’s may think just ask yourself one question - who cares?

Big thanks to Pavan Trikutam, Monte Brown, Corey Grusden and Kyle Crawford for reviewing and editing this post before publishing.

This was originally published on May 24, 2017 on pbj.me/writing/who-cares.html.

DEV Community: pbj