Code Computerlove logo Front End Tools & Docs

How to prevent potential TS performance issues, simply

Matt Pocock talks about a way to optimise your app's IDE performance by simply moving the right types to an interface! Extending HTML types is a common occurence. We use it all the time for things like buttons, where you want TS to know about all of the HTML attributes available on that button but you also want to be able to add your own.

Type Example
type ButtonProps = React.HTMLAttributes<HTMLButtonElement> & {
  extraProp: string;
};


const Button = ({ extraProp, ...props }: ButtonProps) => {
  console.log(extraProp);
  return <button {...props} />;
};

It turns out that this pattern is very slow. The advice is to change these type to an interface instead and suddenly everything is much quicker!

Interface Example
interface ButtonProps extends React.HTMLAttributes<HTMLButtonElement> {
  extraProp: string;
}

But why is this? You may have heard that interface is slightly faster than type but this is not quite true. In fact, interface extends is slightly faster than &, which is why this is an optimisation.

Check out the full article on Total TypeScript.

Jhey's Spot

This week, on Jhey's Spot: use scroll-driven animations instead of Intersection Observer to start your animations at specific scroll points in the viewport!

See the Pen CSS Scroll Driven/Triggered Image Reveals 2024 by Jhey (@jh3y) on CodePen.

See the Codepen here and the Tweet here

Storybook 8 is out

In a blog post Storybook announced that they have released v8. This has been much quicker than the release from 6 to 7 and, as far as I can tell, doesn't require much of a change. Mostly, it just works. As long as you upgrade by using the upgrade command (as below) in a codebase that already has Storybook it works great.

Upgrade Storybook
npx storybook@latest upgrade

So what's new?

  • 📸 Built-in visual testing
  • ⚛️ React Server Component support
  • 🎛️ Upgraded Vue and React control autogeneration
  • ⚡️ Rearchitected Vite support, Vitest testing, and Vite 5 support
  • 🧪 2-4x faster test builds
  • ✨ Refreshed desktop UI
  • 📲 Rebuilt mobile UX
  • 🙅‍♀️ Removed React dependency for non-React projects

The boilerplates have been upgraded and the thing I have noticed is that boot times seem to be a lot quicker, which is great. Also, due to using Vite now HMR feels a lot better too.

The End of React Router

Now that Remix has an SPA mode React Router has become kind of defunct. Remix has been built on top of React Router since the start but allowed you to have a server handling routes (plus loaders and action functions etc). The latest release introduced "SPA-mode" that allows Remix to render a completely static site, so no server needed. This is, essentially, what React Router is so it's probably going to go away and the team can focus on Remix.

As ever, Theo has a great video on it.

Million Lint

I've mentioned this before and tried it without success but it's progressing so I'm going to try it again.

Million Lint is a VSCode extension that keeps your React website fast. It identifies slow code and provides suggestions to fix it right in the editor as you code. It's like ESLint, but for performance!

It's kind of like React dev tools, only without the complexity and deep knowledge of RDT needed to use it!

Read the blog post and try it out.

TS Config Cheatsheet

A handy cheatsheet from Matt Pocock on that potentially huge, complicated file tsconfig.json. If you want to know what all those keys and properties mean that you have to put in there check out the cheatsheet.

Matt also gives you his opinionated (but likely spot on) config you can use. Afterwards, it's a nice breakdown of the options and a description of what they all do/mean.

Nue CSS 🤦

Have a read of this. Then we can discuss!

Today we're launching a new CSS framework that is quite literally "out of this world". So absurd that it is possible to build an entire website with the same amount of CSS that goes into a single Tailwind button. Or even crazier: three websites with a single Tailwind Catalyst button.

The number of components/pages that can apparently be built with the same amount of CSS as a Tailwind button.

This is, quite possibly, one of the most opinionated articles I've ever read. You can tell that it's written by someone who doesn't like, or really understand, Tailwind.

I don't mind Tailwind. We've spoken about it before. It has its uses and its place and for my personal projects I will sometimes reach for it if I want to get something up quickly. I wouldn't necessarily recommend it for a larger, multi-person project like we have here, but you could make it work for that too.

The examples in the artictle are biased, and very much the exremist of extreme examples. I can make a Tailwind button look nice in a couple of bytes of CSS! They also don't seem to understand the concept of a componentised codebase. All the examples suggest that the markup for the component needs to be written each time the component is used, but that simply isn't the case.

And, because your styles aren't manually written but based on the classes you use, you know that when you change a class, remove a class, add a class, your CSS will always reflect exactly what is being used. No real technical debt there, unless you have components that aren't being used.

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!