301 Using external JavaScript libraries [1d]

Updated . Posted . Visible to the public.

Just like we use gems on the server, we use third party JavaScript libraries in the browser. These typically provide functionality like:

Important

Work on this lesson in builder mode.

Learning goals

  • You can explain how a third-party library gets into our app: a package manager records it in package.json, pins the exact versions in a lock file, and the build pipeline bundles it.
  • You can evaluate a library before adding it — maintenance, popularity, tests, dependencies, size — and prefer boring technology over the newest option.
  • You can explain why the size of your JavaScript matters to users and check what a package costs (e.g. on Bundlephobia).
  • You can add a library and import only the parts you need as ES modules.
  • You can explain how npm-style package managers resolve conflicting version requirements differently from Bundler, and what that means for your bundle.
  • You know pnpm as the alternative package manager we also use and how it differs from yarn 1.

Resources

Read what's new to you, skim what's familiar, skip what you already master. Stop when you can meet the learning goals.

Your agent can also generate an overview, a tutorial or an explanation for anything here, tailored to what you already know. Just ask.

Adding a library

We generally use the yarn add command to add third party libraries to our application. It will persist the desired library version within the package.json file and pin matching dependency versions at the auto-generated yarn.lock file. You shouldn't ever have to manually edit the latter. Have a look at how to manage versions with a package.json.

Yarn gives us access to the NPM ecosystem. Take a few minutes to browse npmjs.com Show archive.org snapshot , the central registry. It is a great place to look up JS libraries with their dependencies and version history.

Choosing a library

Read the card "Choosing the right gems for your project" and the article " Choose Boring Technology Show archive.org snapshot ".

When you add a new library - be it JavaScript, Ruby or anything else - you should first get a general overview of the most popular solutions. To chose a single "best" of those, ask yourself questions such as:

  • Is the library still maintained? When was the last commit? Are new issues being answered? Note that some projects are rightfully "feature complete", so not having any recent commit can be okay at times.
  • Is it rather popular? If yes, there is an increased likelihood that common edge cases were already adressed and that someone would keep maintaining the library if the original author stops doing so.
  • Does it contain tests? The code quality of our libraries should generally be around the same level of our own standards.
  • Does it have a ton of dependencies? Fewer is better, in this case.

Sites like the Ruby Toolbox Show archive.org snapshot (only for gems) or npm compare Show archive.org snapshot may help you filtering out libraries as they try to combine similar statistics in a single score.

Exercises

Evaluate searchable selects

Research solutions for a “searchable select” JS-component for your MovieDB. Filter results based on the abovely mentioned guideline, and grade them for their

  • GitHub star/issue ratio
  • Compatibility with your frontend build pipeline
  • Size
  • Browser Compatibility
  • Features
  • Developer Experience
  • Customizing optics

Timebox Show archive.org snapshot : 60 minutes. Don't add the searchable select component to your MovieDB.

A closer look at lodash

Take a look at the popular lodash Show archive.org snapshot library.

  • Try to understand what it does.
  • Why does it mention "x kB gzipped"? How is that important?
  • Try to add lodash to MovieDB
    • Use yarn add lodash, then import it in your compiler e.g. like this: import debounce from 'lodash/debounce'
    • Can you find a way to make use of it?
  • Often, JavaScript libraries come in "minified" versions. What does that mean? Is it important?

One more thing about Yarn / npm

There is one significant difference between JavaScript package managers and Bundler: In Ruby, only one specific version of a gem can be active at any one time. With Yarn or npm, if multiple packages depend on different versions of other secondary packages, they can receive different versions of those secondary packages at the same time. You can read a little bit about it here Show archive.org snapshot . Note that:

  • This is possible in ES6, but not in Ruby:
    • Bundler enforces a single compatible version of each gem in the Gemfile.lock, which can later then be loaded to the current Ruby process. Every other dependency has access to the same loaded code
    • Yarn on the other hand allows mismatching version constraints of the same dependency, and guarantees that each package receives a matching version of the same dependency.
  • It can be useful as it allows you to include two libraries that would otherwise not be compatible, e.g. when one relies on jQuery 2 and the other on jQuery 3.
  • Loading the same library twice can also be problematic: The bundle size increases and the two copies do not share any state.

Adding a datepicker

In your MovieDB, change your "release year" field to "release date", now allowing precise dates. Use Flatpickr to add a UI. Remember to use unobtrusive JavaScript.

Check it out on Bundlephobia Show archive.org snapshot .

Embracing ES6 modules

Change all your global JavaScript functions and classes so they export ES6 modules. Any code that uses these functions and classes should import the newly created modules. Your code should no longer define anything on window.

Alternatives

MovieDB uses yarn 1 because that is what our base app ships with. yarn 1 is no longer maintained and yarn 2+ never caught on; in our projects we increasingly use pnpm Show archive.org snapshot , which is fast, disk-efficient and stricter about dependencies. The commands map one to one (pnpm add, pnpm install), the lock file is pnpm-lock.yaml. See the card Our Rails stack for the bigger picture.

Profile picture of Henning Koch
Henning Koch
makandra.de
Say thanks
Last edit
Michael Leimstädtner
License
Source code in this card is licensed under the MIT License.
Posted by Henning Koch to makandra Curriculum (2017-02-03 16:05)
This website uses short-lived cookies to improve usability.
or learn more