New TypeScript Features

New TypeScript features

Matt Pocock talks about a new feature coming to TypeScript 5.5 in the next couple of months. This update will include a PR titled: "Infer type predicates from function bodies using control flow analysis". Sounds a bit confusing, but Matt breaks it down nicely, and we'll summarise here.

Currently, you can narrow down types with an `if` statement:

1if(typeof something ==== 'string')

However, you can't do this with an inferred function. TypeScript gets all confused and doesn't know that the function narrows the type unless you add a bunch of hard-coded types as the return:

1function isString(value: unknown): value is string {
2  return typeof value === "string";
3}

If we were to change that return value to a number TS wouldn't complain, but the types could be wrong!

The PR simply adds the ability to write a function that takes an `unknown` and returns whatever you add your check for:

1function isString(value: unknown) {
2  return typeof value === "string";
3}

Check out the full article on Total TypeScript.

Jhey's Spot

This week, on Jhey's Spot: a bookmarklet that adds a magnifying glass to the page you're on!

See the Gist here

Remix Dev Tools

Remix has a cool dev tools 'extension' that sits on your dev site and shows you a bunch of cool stuff. It's being used on our first Remix client, too!

Check out the docs site here. It has recently been updated with some handy new features. With the new Remix Vite server, it's even easier to add, as you just add the Vite plugin and it's done!

It's a great tool for debugging and seeing what's going on in your app. It's also a great way to see how the server is working and what's being cached.

• See every loader data, route params and server information in real time. See your deferred data load in and see your cached loader information. No more console.log(). Get the information you need when you need it.
• See all your navigations, submissions and everything in between in real-time with the timeline tab. No more guessing, no more wondering, see exactly what happens behind the hood.
• See all your project routes in a tree/listview, directly open them in the browser with a click of a button, and see which routes are currently active on the page. No more guessing.
• See the difference in HTML rendered on the server and the client and figure out what is causing your hydration issues.
• See your server logs in real time:
  • Loader/action hits
  • Server errors
  • Cache cleanup
  • Cache headers
  • Cookies set
• Granular logs for everything that your server does, so you don't have to wonder ever again!

Remix has moved to Vite!

In version 2.7 the Remix team stabilised the Vite plugin, so it's safe to use! I've checked it out and, although it takes longer for the initial server to run (it bundles stuff at this point rather than at build), the DX is so much better. HMR is complete. Pages update without a refresh. 'State' is kept.

I've tested this out, and it's quite cool. I've converted the Remix Starter to use it this week and will chat to LG about updating it for their project too.

Read the changes here.

LocatorJS

I've mentioned this before, but I do find it so useful: on any React-based page, hold alt and click a component to go directly to it in your editor!

Get it on the Chrome Webstore.

Is TDD still relevant?

I've seen a couple of tweets/posts this week about the suggestion that TDD doesn't really work for the web. How can you start with a test when you don't 100% know what you're building? Sure, sometimes you do get all that information, but not often, so writing a test before starting to code isn't practical.

Here's Theo's tweet about an article about it.

The following point from the article sums it up:

Too many flaky tests. Too much time spent getting the tests to pass after making a tiny change that I knew was correct but the tests didn't. Too many integration tests that made people wait 20, 30, 40 minutes until they could merge their change, only to reveal — months later — that they never tested anything. Too many times have I fixed a bug and knew it was fixed because I tested it manually, thoroughly, and was 100% sure that I know how the code works and that this can't happen again, but then spent hours — 10 times longer than it took me to fix the bug — to write a test only to prove what I knew all along, that the bug is fixed.

My projects on the go

• Front End tools upgrade (it's a year out-of-date!)
• Front End challenges website
• API flattener tool needs upgrading
• Keeping the starters upgraded!