DEV Community: jayebird 🐙🏳️‍🌈

How do you test a design system?

jayebird 🐙🏳️‍🌈 — Thu, 25 Feb 2021 17:52:17 +0000

I've inherited a component library that I'm bringing back to life.

In the past I've worked on React component libraries and used tools like Storybook to develop them. Testing these is pretty easy - I tend to use mostly react-testing-library and jest.

But this particular library is different—each component is:

a scss file for styling
optionally, some javascript
a markdown file that combines written guidance for using the component with code samples and live previews

It's not that different from the GOV.UK design system.

Testing the javascript parts is easy enough, but it's only a small part of the overall library.

How do you go about testing something like this in a robust way?

The server is back, baby

jayebird 🐙🏳️‍🌈 — Wed, 30 Dec 2020 16:56:12 +0000

2021 could well be the year of the server's glorious return.

The React team at Facebook have previewed server components, and the people at Basecamp have released Hotwire.

// Detect dark theme var iframe = document.getElementById('tweet-1341072021099327489-294'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1341072021099327489&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1341420143239450624-929'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1341420143239450624&theme=dark" }

The approaches are very different, but both tools seem to be about:

writing less JavaScript
doing more on the server
dealing in plain old HMTL whenever we can

Why does it matter?

The past few years of web development have been about shifting as much as possible off the server.

Companies like Netlify have been arguing hard for making our apps as static as possible, and building our dynamic features with client JavaScript,APIs and serverless functions.

This is arguably a faster, more secure way of doing things, but it does have downsides.

Doing everything statically can add complexity, and shifting the burden of work from our servers to the user's browser makes it harder to progresssively enhance our apps: we're beholden to the speed of the user's connection and hardware.

// Detect dark theme var iframe = document.getElementById('tweet-1344376354955935744-818'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1344376354955935744&theme=dark" }

Client-rendered single page apps still have accessibility issues that are hard to solve.

After a few years of this, it looks like the pendulum is now swinging back in the other direction.

Maybe the server is good for some things after all!

How do they work?

React's server components are a carefully-considered redo of what Next.js does now with getServerSideProps.

With Next.js today, you can only do server-side operations on top level "page" components. This would remove that limitation.

Meanwhile, Basecamp's Hotwire is an evolution of the Turbolinks library that comes standard with all new Rails apps.

It seems intended to be a Rails companion, though I expect there's a way to use it seperately.

Should I learn it now?

Probably not quite yet!

React's server components are a way off yet—all we can do is experiment with the demo.

While Hotwire is apparently production-ready, it'll take a little while for examples, documentation and patterns to get good enough for me to consider using it, at least.

What's the reaction been?

Everyone seems to love Facebook's server components, though there's a lot of unanswered questions.

// Detect dark theme var iframe = document.getElementById('tweet-1343086245665067010-798'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1343086245665067010&theme=dark" }

People seem more confused about Hotwire. Maybe it's a sense of humour thing?

// Detect dark theme var iframe = document.getElementById('tweet-1341479796287676416-37'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1341479796287676416&theme=dark" }

Either way, I'm keen to see where this goes.

Exciting times ahead!

Using JWTs for authentication—is it worth the effort?

jayebird 🐙🏳️‍🌈 — Mon, 14 Dec 2020 23:12:21 +0000

When you look for advice on how to authenticate users of an Express/Node.js API, the most popular answer seems to be "use JSON web tokens".

I took this advice as read when I was building my first few APIs. I dilligently built the middleware for signing, verifying and revoking tokens, plus the client-side code for keeping them.

A few years later I discovered Rails. I was very late to the party, but the simplicity of using Rails session cookies was really attractive after the hassle of building secure authentication again and again.

So, I've recently started building another Node/Express API, and I've decided to use the same session approach. It's been much less stressful.

The setup for express-session looks like this:

server.use(session({
    store: new (require("connect-pg-simple")(session))({
    }),
    secret: process.env.SESSION_SECRET,
    cookie: { maxAge: 30 * 24 * 60 * 60 * 1000 }
}))

And then in my route handlers, it's as simple as saying:

// where 'user' is the user who has just authenticated
req.session.userId = user.id

Because sessions are stored on the server and the client only gets an encrypted cookie, this seems foolproof and easy to maintain.

The cookie is passed in automatically with every request - it just works.

So, I'm wondering why people bother with the extra overhead of JWTs at all?

The reasons I normally hear are:

'JWTs are more scalable when your app needs to grow'

I guess this might be true if you're keeping sessions in the memory of a particular app instance, but any realistic implementation involves an external session store.

Even my minimal example above uses a table on the PostgreSQL database that powers the rest of my app.

That database is an external service—it's horizontally scalable out of the box. This doesn't seem to be a realistic problem?

'JWTs are more secure'

Recently I've seen lots of people suggesting it's easier for JWTs to be stolen by XSS attacks, especially if you keep them in localStorage.

The current wisdom seems to be that you need to store them as a httpOnly cookie. So...why not just use cookies to start with?

'JWTs are stateless'

This one I do understand - a stateless API is ideal, easier to test.

But what's the harm in a session that stores just the user's ID, say? Is that tiny bit of state really that bad?

To take it a bit further for the sake of argument, let's say we used the cookie-session store.

What's the difference between this and using a JWT in a cookie? Just the way the token is formatted/encrypted?

'JWTs still work when the API is on a different domain'

This one makes sense too - cookies should be restricted to a particular domain, and if we're making requests to a third-party API on a different domain, we'll need to manually handle a token.

But how do we square this with the best practice to store JWTs in cookies rather than localStorage from earlier?

Am I wrong?

What am I missing?

What situations would a JWT be worth the effort in?

Do you have a preference for sessions over JWT, or the reverse?

I've published my first WordPress plugin!

jayebird 🐙🏳️‍🌈 — Mon, 14 Dec 2020 00:21:42 +0000

Showing users things near them is a really common user need for all sorts of apps and websites.

It could be used to power anything from "branch finder" features on retail sites to nearby drivers on a ride-hailing app.

For my day job, I need to build this kind of functionality roughly once every few months, so I was keen to find a way to package it up into something reusable.

I've implemented it in Node.js and Rails before, but I was curious about a WordPress implementation - which is what this is.

After making over half a dozen apps like this, you start to wonder if there's a better way!

How it works

It's a three step process:

You provide a geocoded dataset to search. They could be shops, offices, childminders, zoos—anything, really. You make sure that they have latitude and longitude metadata.
The user provides their location with a text input, which we also geocode. We use Nominatim's excellent free API to do this.
Finally, we use the haversine formula in SQL to calculate the distance to each point in the dataset. It takes into account the curvature of the earth, so we get super-accurate results even on international scales!

The plugin

Take a look and tell me what you think!

It's my first WP plugin that I've actually gone to the extra effort of publishing, so I'm keen to keep adding features.