Related content: Using Sitecore’s Flexibility in UI Development
We discovered we could still step out of the cumbersome world of third-party dependencies without abandoning the benefits of using versioned, reusable, and tested utility libraries and plugins.
But the world ain’t all sunshine and rainbows
Like any bad breakup, parting ways with jQuery was a breath of fresh air, but I’d be lying if I said we didn’t miss certain things about it:
- Ajax calls (or more accurately, ajax calls before the simplicity of the Fetch API) are downright ugly to write.
- Whether you love them or hate them, jQuery is well-known (some might say notorious) for its massive plugin ecosystem. Getting rid of core jQuery in our projects meant we also had to abandon using any and all jQuery plugins. Suddenly, adding something as simple as an accordion to a site meant we either had to build our own from scratch, or find a third-party plugin that didn’t have a jQuery dependency.
And that, boys and girls, is how DEGJS was born! With the help of a package manager on our side, it occurred to us that we could still step out of the cumbersome world of third-party dependencies like jQuery without abandoning the benefits of using versioned, reusable, and tested utility libraries and plugins.
What exactly is DEGJS?
Some of the first DEGJS modules we wrote were actually small shims for missing or annoying-to-use native JS functionality, many of which we took for granted in our jQuery days. For example, jQuery’s .wrap() and .wrapAll() methods are beautiful abstractions of the somewhat lengthy bits of code needed to do the equivalent DOM manipulation in vanilla JS. To compensate for this, we added our own .wrapElements() method to our domUtils module, a collection of low-level DOM interaction utilities—but unlike the all-you-can-eat jQuery, these utilities can be individually imported into projects as needed.
But the fun didn’t stop with simple utilities. DEGJS also contains quite a few of the more robust plugins we use across many of our web projects, including tabs, accordions, overlays, and form libraries. Some of my personal favorites include:
- dialogLoader: A rather clever module created by UI Engineer Anna Scheuler. This module allows you to use (and polyfill) the recently standardized dialog element easily and without worrying too much about its fairly limited browser support.
- numericycle: Created by UI Team Lead Ryan Heap, this cool little plugin takes two numbers and smoothly animates between them.
- formValidation: My pride and joy! As its kind of boring name implies, this is a modular, promise-based form validation plugin, free of third-party dependencies and built on top of native HTML5 validation.
There are quite a few more worth mentioning, but I encourage you to explore the GitHub page to see them all.
How it works
Each DEGJS repo is written as an ES6 module and structured to work with JSPM. What this means in practice is that if I’m working on a project that needs the aforementioned formValidation plugin, for example, I can simply type the following into the command line to install it:
I’m oversimplifying things, of course, as getting this to work in our build tools wasn’t exactly trivial. But once we figured out how to configure it, using DEGJS within JSPM really has become an incredibly powerful, yet easy-to-use, part of our day-to-day JS workflow.
But what we didn’t anticipate at the beginning of this undertaking are some of the more subtle, but no less important, benefits:
- Creating internal tools is an excellent opportunity for new team members! It helps them learn the team’s coding styles and best practices, and gives them a tangible way to contribute almost immediately to tools and build processes.
- Thanks to GitHub, pull reviews help everyone learn. Any changes to a module are submitted for review by other team members, who then comment and make suggestions before the code is merged and published as a new version. This is an awesome learning mechanism for both the code contributor and the reviewer.
- Likewise, JSPM’s reliance on Git’s tagging system allows us to (somewhat) effortlessly version our modules. Dependency management is handled for us and it’s rare that we even have to think about it.
Even though our transition to DEGJS has been great, I’d be lying if I said there hasn’t been some turbulence:
- Plugins need to ride a very fine line between simplicity and flexibility. On the one hand, you want your plugin to be generic enough, with plenty of configurable options, to be useful across as many projects as possible. Then again, it’s also easy for the codebase to become so niche or obfuscated that it’s difficult for anyone other than its creator to see its benefits. Thorough, thoughtful documentation helps ease this pain.
- Bugs, bugs, bugs. No matter how clean your code is, bugs happen, and they always seem to happen at the most inopportune times. This is a normal part of software development, and versioning makes this relatively painless to solve, but no one enjoys troubleshooting a plugin of their own creation when they’re trying to hit a deadline. This is where pull requests and code reviews can really be lifesavers.
Where we’re going, we don’t need roads
This process hasn’t always been easy. It takes a lot of work—more than I think we realized at the beginning—to build and maintain your own coding ecosystem. But controlling your own destiny by way of the tools and processes you use can be very liberating. I’d never want to go back.
Want to create the best possible user experience for your customers? Our talented creative design and experience team can help.