Once you start using ESM, you realize that most libraries out there are not written in ESM, nor do they include ESM builds. Many are still using globals, and those that target Node.js use CommonJS (CJS). What can we do in that case? Unfortunately, ES Modules are not really designed with any import (pun intended) mechanism for these syntaxes, but, there are some strategies we could employ.
To add icons, you just drop them into a designated icons folder. If you no longer need an icon, you simply delete it. To use the rocket.svg icon in a template, the syntax is as simple as <svg-icon icon=“rocket” />. The icons can be scaled and colored using the CSS font-size and color properties (just like an icon font). If multiple instances of the same icon appear on the page, the SVG code is not duplicated each time. No webpack config editing is required.
Firstly, mailto links make it hard to copy the address, for example if you want to share the email address with someone else. Secondly, some users use more than one mail app, and the link just uses whichever has been setup as the default, without giving them the option to use the other. And finally, many users don’t have an email application set up, which means the link can take them to a dead end or down a rabbit hole.
Now that I’m using more and more TypeScript in my day-to-day job and my side projects, I feel I’m more prepared to confront types. Actually, not confront, but use them in my favor. This post is my attempt to help developers think more in types and understand this mental model.
Time has identified dozens of “responsive best practices” that are simply no longer necessary or no longer best practices. With a critical eye, we’re able to reduce quite a bit of cruft and overhead, which improves the overall customer experience.