[Robin]: There’s a part of any front-end codebase that’s like the core of a reactor—all the features in an application are dependent on this tiny amount of code; fragments and snippets that are the load-bearing posters of your codebase. That sounds obvious but in practice, it’s hard to see what’s load-bearing and what’s trash. Maybe the trash is load-bearing!
(That’s when you have some real design systems issues.)
The reason why I mention this is that one problem we’ve had in our front-end is one I haven’t heard anyone else mention before: for a long time it was almost impossible to write good front-end code in our codebase. Our components were so strange and peculiar, so dependent on custom CSS or page-level styles that you couldn’t possibly do the right thing when you were building a feature.
All too slowly I realized that if we didn’t fix these core parts of the front-end then everything our engineers built in the future would be nothing but hacks on top of even more peculiar hacks.
One example I discovered recently was with our tables. At Gusto, we have two codebases; our component library (which consists of our reusable React components and core styles) and our primary web application (which consumes the component library).
I stumbled upon code like this in our primary web app:
table.big-table {
tr.big-table-row td.cell {
background-color: #eee;
}
}That’s…not great! But why is this so odd? Why would a very capable and smart engineer hack together code like this? Well, after investigating the core of our codebase, and looking at the very bottom of the stack of styles that make up our component library we had a ton of code that was way too specific.
And so the only way to get around that is to make these nasty specificity hacks in the primary web app.
In our component library we might have styles like this:
table.table > th.table > td { }Code like this isn’t terrible but it’s effect on the system truly can be catastrophic. And as I mentioned earlier I often imagine that the core of a codebase should be seen as a nuclear reactor—a machine that can leak toxic code into other parts of the codebase if we’re not paying attention. And it’s radioactive code like the stuff above that poisons everything built on top of it and ensures that it’s quite impossible to write high quality front-end code.
If you want to change one small thing and it requires what feels like a hack, like the specificity issue above, then your reactor is leaking toxic code and you need to fix it before more issues build up over time.
And so we need to be constantly reminding ourselves of the core of our codebase: are we building hacks on top of hacks or are we extending the core and building something that will last on top of it?
So we must always remember that if folks have to fight the very core of a codebase then this is a signal that the reactor is on fire. Because smart people will do extraordinarily dumb things when they don’t have the tools and support that they need. And so to help them we must always remember the core, we must always be finding ways in which to make it simpler and less error-prone.
And then we need to go fix it.
? From the Blog
Styling Links with Real Underlines
Ollie Williams brings up a lot of interesting points in this post, especially where he argues that:
In graphic design, underlines are generally seen as unsophisticated. There are nicer ways to draw emphasis, to establish hierarchy, and to demarcate titles. […] But the web is different. Hyperlinks are the defining feature of the internet; and from the internet’s inception, they have been underlined. It’s a universally understood convention. The meaning is crystal clear — an underline means a link.
Underlines are a particularly webbish design convention and it’s pretty odd that native apps rarely appear to use them. I guess it’s because websites generally have so much more longform text.
Either way, it’s pretty neat that the text-decoration-skip-ink CSS property has now been added to our tool-belt to control how underlines are styled—but!—the neatest thing is that the default underlines are now much prettier.
The default value of text-decoration-skip-ink is auto (left) and a value of none (right). So! In my opinion this is the coolest thing.
The Best (GraphQL) API is One You Write
Chris has jotted down some thoughts after talking with Simen Skogsrud and Knut Melvær on a recent ShopTalk episode where they discussed Sanity which is a cloud storage service for JSON data, and it can also act as a CMS.
Chris looks into their special query language called GROQ which is super interesting and gives us developers a lot more control than GraphQL.
Maskable Icons: Android Adaptive Icons for Your PWA
Tiger Oakes looks at a brand new API that was added to the W3C spec called Maskable Icons. Platforms like iOS or the various manufacturers that use Android all have different icon shapes and that can get a bit tricky for us developers when building Progressive Web Apps that can be used across all these platforms.
Tiger writes:
Maskable icons can be any size, and you can continue to use the same sizes that you’d use for normal transparent icons. But when designing the icon, ensure that important information is within a “safe zone” circle with a radius equal to 40% of the image’s size.
Tiger has even created a super nifty tool called Maskable.app that shows how different platforms might mask or cut off your app’s icon. It’s sure to be super handy if you’re working on a Progressive Web App at the moment.
Going Buildless
Pascal Schilp writes in to tell us all about how not to use a build process or a bundler and instead use a series of much smaller and less complex tools to get the same effect. Heck yeah!
Pascal walks us through every little detail of building this Reddit Progressive Web App doing just that:
The point here is to make a fun application, while using some of the latest features, drop some buzzwords, and have a low barrier for entry. As Fred Schott would say: “In 2019, you should use a bundler because you want to, not because you need to.”
Filestack Workflows
Filestack Workflows allows developers and non-developers alike to streamline content tasks into a simple to use UI, within a single API call. Take a look at our step-by-step guide that walks you through automating and customizing your digital assets.
Let’s end with a tiny little CSS trick.
If you need multiple borders on an element, there are lots of ways to handle that. You can use multiple box-shadow values to take you a long way. But what if those “borders” needed to be gradients? Things get trickier. You might have to layer some pseudo-elements or nest some elements.
But another idea is to apply those gradients only to particular sections of the box model with background-clip.
