Brian Bancroft

You Might not Need to Wrap That

June 09,'19 | Programming

Javascript and NPM and wonderful things, even when they aren't. In the spirit of open source, I get to build many new things by standing on the shoulders of others — and there's no shortage of shoulders to stand on! But sometimes, this gets a little overwhelming. When do I choose to start from scratch, and when do I try to use something that someone else has built? In a few words, here's my thought process:

The General Rules:

First, if your career or hobby goals revolve around building at this level of abstraction, stop reading this article. You want to know this stuff if you're junior, and you're building things at the applied level.

If you haven't been developing for a long time, you might want to "use the library" for the higher levels of abstraction, because there are many things you shouldn't build to just accomplish the little thing you want. If you're building an API endpoint or a new feature for a user interface, you don't want to build your own semiconductors or keyboards, you don't want to create server hardware, and you certainly don't want to create your own JS framework:

Zero Days since JS Framework

(Well, most of us don't)

At many levels of the abstraction chain before "applied", there are those who have spent hours building, testing, and refining that thing. It's when the level of abstraction gets closer to applied that you really have to start asking yourself...

Specific Rules

When you start asking "should I use this library" at the applied level, you're going to want to start doing the research so that you don't run into serious problems too far in. Here are the ones I go by:

  • If you wanted to do something that's not listed in the hello world examples, is it easy to figure that out with the rest of the documentation?

  • Are the library maintainers or users on Stack Overflow or Github Issues? They don't owe us any more time, but it helps to know whether there's a place where we can call for help when things get dicey.

  • In addition to the use case you're planning to use the library for, can it tackle all the future and potential future use cases you think you're going to need it for?

  • Is the library actively maintained?

  • Will it take less time to use the library than to do it yourself?

  • Has there been no security issues associated with this library?

If you've answered no to any of these questions, it's not an automatic no. Instead, you're going to have to look deeper. If you've answered yes to all of the questions, you might have found something that will make your life much easier!

One Story

Often I make web maps, and I've been doing it within React a bit more as of late. I'm a fan of MapboxGL in my work, just for how smooth its operation can be and the people which support it. Now, I often reach for UI libraries to do the thing I want and I started to go the same way with MapboxGL. In React-land, there are two libraries in use: react-map-gl and react-mapbox-gl. Here's a chart of their relative popularity:

z-npmcharts

(source)

React-Map-GL (https://uber.github.io/react-map-gl/#/)

This library is a friendly wrapper built around MapboxGL for React applications. It is owned by Uber, and maintained with a lot of care and love by its team. But it wasn't built to have the entire suite of tools in the Mapbox GL JS library accessed with ease. It even offers a friendly reminder (https://github.com/uber/react-map-gl#before-you-begin). With this library, tasks such as the addition and removal of layers isn't something that's easy to pull off. And while there are secondary libraries such as deck.gl that promise beautiful layers, it's not something I want to add to a slim React app just yet for what I want.

React-Mapbox-GL (http://alex3165.github.io/react-mapbox-gl/)

This library is a declarative wrapper built around MapboxGL for React, as well. The library is around 50kb size, there are no security issues, and there appears to be a small community. It also appears that I can build on top, which is nice. And I could've gone for it, except that I realized that it would take as much time to build my own wrapper as it would to learn this one.

The DIY Option

But the truth is that often, you can just use the library as-is, and build out functionality as required, suited to your particular use case. Mapbox, the company behind my favourite mapping library even shows how themselves https://blog.mapbox.com/mapbox-gl-js-react-764da6cc074a and I was able to construct something similar to what's below:

import React, { Component } from 'react'
import mapboxgl from 'mapbox-gl'
import styled from 'styled-components/macro'
import PropTypes from 'prop-types'
const MapContainer = styled('section')`
height: calc(100vh - ${props => props.theme.headerHeight});
`
class Map extends Component {
constructor(props) {
super(props)
const { lat, lng, zoom } = this.props
this.state = {
lng,
lat,
zoom,
}
}
componentDidMount() {
const { lng, lat, zoom } = this.state
const { accessToken } = this.props
mapboxgl.accessToken = accessToken
const map = new mapboxgl.Map({
container: this.mapContainer,
style: 'mapbox://styles/mapbox/streets-v9',
center: [lng, lat],
zoom,
})
map.on('move', () => {
const { lng, lat } = map.getCenter()
this.setState({
lng: lng.toFixed(4),
lat: lat.toFixed(4),
zoom: map.getZoom().toFixed(2),
})
})
}
render() {
return <MapContainer ref={el => (this.mapContainer = el)} />
}
}
Map.propTypes = {
accessToken: PropTypes.string.isRequired,
lat: PropTypes.number,
lng: PropTypes.number,
zoom: PropTypes.number,
}
Map.defaultProps = {
lat: 0,
lng: 0,
zoom: 0,
}
export default Map

There are drawbacks to using your own thing at the applied level. First, it's likely that the library has more robust testing. There's also a chance that the library might be a bit more performant. But by doing it yourself, you might learn a lot more of the fundamentals from the thing which you build! If you depend on libraries, you don't know what new things about the language you might miss out on...

z-is-even

home
portfolio
posts
contact