Turns out, all libraries out there (google for “tag input javascript” if you’re curious) that do this have at least one of these flaws.
- Feature bloat
- Human unfriendly
- Addiction to dependencies
Instead of creating separate components for, say, tag input and autocompletion, most of these libraries try to do it all, and fail miserably at doing any one thing well. This is the defining characteristic of modular development, where we define a (narrow) purpose for what we’re building and we set out to build the best possible solution to meet that purpose.
Multi-purpose libraries end up doing a lot of things I do not need or want, while single-purpose components typically do exactly what you need.
Being user friendly is why we build these libraries, and yet I couldn’t find a single library that I would’ve used over a simple <input type='text' /> and telling my humans to enter tags separated by a single space. The vast majority of these presented inconveniences such as being unable to walk around the input like we do in an input tag, insert tags in any position, or not even allowing humans to edit tags once they receive the “this is a tag” treatment.
Human-facing interface elements must be sensitive to the needs of the human. Sometimes we have to wonder if a component is even worth the trouble. Wouldn’t a simple
<input>be more amicable than an inflexible “tag input” solution? Is the component more useful to your humans?
Finally, most of these libraries tie themselves to a dependency. If I really liked one of them, I probably would’ve needed to commit to jQuery myself. Or Angular. Or React. It doesn’t matter what their “big dependency” is, the point is that it constraints the consumer from being able to easily port the component to different projects with other assortments of frameworks or libraries.
The fact that most of them count jQuery among their dependencies leaves much to be desired.
This article will explore the approach I took to build Insignia in just one day, as I think you may apply some of these concepts to any development you do on a daily basis.
Insignia
Insignia has the purpose to make tag editing simple. If you want to suggest tags to your humans, based on the results of an API endpoint or events over a WebSocket, you are certainly welcome to do that, but Insignia won’t take any part of it.
If I needed something to suggest tags for humans using Insignia, I wouldn’t create a plugin system. The DOM is the plugin system. I would create a separate component to do just that. It would also be a component that makes sense on its own, when paired with another input that deserves a suggestion mechanism. For instance, that theoretical component might work well enough to suggest dates on a field that’s already using Rome for date input. This way, the composable small components I create could serve me well for other projects, and hooking them to my framework of choice shouldn’t take a lot of effort.
The purpose then is to create a tag editor that’s human friendly. Humans should be able to enter values into the field even when JavaScript hasn’t finished loading. Once JavaScript loads, the tags that are already in the field should be extracted into a prettier visualization, but the human should still be able to remove them, edit them, and walk through them with the arrow keys.
A minimal API would also go a long way towards being able to translate the altered visual representation into a collection of tags, something the implementation shouldn’t have any problem putting together.
Once I’ve settled for a purpose and I roughly understand how the interface should look like, there’s one more pause we need to take before starting to smash our fingers on the keyboard.
What kind of browser support will we offer?
This is an important question because there’s nothing quite terrible as suddenly trying to support IE7+ and finding out that even things like Element.setAttribute or Array.prototype.indexOf aren’t even in the browser, let alone Element.selectionStart and Element.selectionEnd.
If you face module development with a “take no API for granted” mentality, you’ll be a significantly happier web developer than most people “dealing with IE8”. You won’t just think of everything in terms of “Is there a polyfill for this?” but rather you’ll be able to see further along and say “I’ll just use a for loop, then”.
Initial Commit
Think of the following as a recipe. Set up an index.html page with usage examples before you have any working code. That’s what you’ll use as a playground for your component. It doesn’t have to actually exist yet, but I find this works best when I also display code for how I want the API to look like.
This kind of preemptive design allows you to predict issues with the API and work your way from basic HTML elements (in my case, just an <input type='text' />), towards the component you want. Effectively, this is the same progression that will be followed by user agents, allowing you to experience the same “rollout” your humans will.
Once you’ve put together the HTML page, start adding the JavaScript and styling. Feel free to code up the examples in plain JavaScript and CSS (basically consuming the API and styling the page itself), but do use whatever module system and pre-processor you feel comfortable with for the library code. These always come with a simple CLI to compile the code into a JavaScript or CSS bundle.
In my case, it just takes the command below to compile any number of CommonJS modules into a single bundle.
browserify main.js -o bundle.js
I usually use watchify during development, which is equivalent to browserify, except it incrementally rebuilds the bundle. For styles I use Stylus, which also comes with a CLI that can be used to watch for changes.
Here’s the entire build and deployment process for insignia.
"scripts": {
"start": "watchify -s insignia -do dist/insignia.js insignia.js & stylus -w insignia.styl -o dist",
"scripts": "jshint . && browserify -s insignia -do dist/insignia.js insignia.js && uglifyjs -m -c -o dist/insignia.min.js dist/insignia.js",
"styles": "stylus insignia.styl -o dist && cleancss dist/insignia.css -o dist/insignia.min.css",
"build": "npm run scripts && npm run styles",
"deployment": "npm version ${BUMP:-\"patch\"} --no-git-tag-version && git add package.json && git commit -m \"Autogenerated pre-deployment commit\" && bower version ${BUMP:-\"patch\"} && git reset HEAD~2 && git add . && git commit -am \"Release $(cat package.json | jq -r .version)\" && git push --tags && npm publish && git push",
"sync": "git checkout gh-pages ; git merge master ; git push ; git checkout master",
"deploy": "npm run build && npm run deployment && npm run sync"
}
Throw in any assortment of .gitignore, .editorconfig, license, changelog.markdown, readme.markdown, .jshintrc, and .jshintignore you feel comfortable with, and you’re ready to get started developing your module.
Make sure to abstract potentially troublesome code into separate modules, so that you can later brush off cross-browser inconsistencies. For instance, I created a './selection' module for getting and setting the selected text range, even when I was initially just working on Google Chrome (which has perfectly functional Element.selectionStart and Element.selectionEnd property getters and setters).
Conclusion
If you approach component design thoughtfully you should have very little issue making a functioning cross-browser component that doesn’t alienate your humans, does what you need, and has a focused API surface that allows you to compose several modules into a complex, scalable application.
Comments