Forem: Maksim Nesterenko

Type vs Interface in typescript

Maksim Nesterenko — Mon, 09 Sep 2024 13:40:34 +0000

Today I learned some funny differences between types and interfaces in typescript.

I used to think there was almost no practical difference between the type and interface and it all boils down to team preferences, but turned out these two behave quite differently when it comes to index signatures. The usage of interfaces can produce unexpected type incompatibilities (=TSC errors). Take a look at this example:

interface C {
    [x:string]: number
}
interface D {
    x: number
}
const d: D = { x: 1 };
const c: C = d; // error
// Type 'D' is not assignable to type 'C'.
//   Index signature is missing in type 'D'.

But change the interface D to type D and it'll be alright.

Rebase a feature branch that is based on another feature branch which got merged

Maksim Nesterenko — Mon, 12 Feb 2024 13:09:54 +0000

So imagine you have 3 branches, where F1 is based on master and F2 depends on F1

*-*-*               (master)
     \ %-%-%        (F1)
            \ x-x-x (F2)

To have F2 up-to-date with F1 you rebase it like

git checkout F2
git rebase F1

or, if someone else is pushing to F1 besides you and your local F1 might be not up-to-date, you do:

git checkout F2
git fetch
git rebase origin/F1

Now, the work in the F1 branch is done and it's finally been merged into the master.

The problem though, is that F2 is still based on top of F1 and contains its commits, so when you open a pull request for F2 against the master it will contain the changes that do not make sense (commits from F1 that got merged already).

The git tree looks like this now:

*-*-*-%-%-%        (master)
     \            
       %-%-%-x-x-x (F2)

What we want here is to have our remaining F2 feature branch to be up-to-date with the master and contain only the relevant commits.

This can be done with --onto rebase flag. So you can do this:

# just to make sure the F2 is up to date with the F1 first
git checkout F2
git rebase F1

# then change the base to be master
git rebase --onto master F1

That'll turn your git tree to be like this instead:

*-*-*-%-%-%       (master)
           \            
            x-x-x (F2)

After this, the commits in your pull request for F2 -> master will make sense again.

Do you really need types for CSS modules?

Maksim Nesterenko — Tue, 14 Nov 2023 13:39:35 +0000

Some teams that use CSS modules + typescript on their projects often consider having type generation for the CSS class names.

File-wise it looks like this:

my-feature.tsx
my-feature.module.scss
my-feature.module.scss.d.ts <-- generated types

The setup for such type generation is well-described in this article with the only exception that the plugin which is recommended in the article is no longer supported and I'd use this one instead.

Let's review the pros and cons of having such type generation on a project.

Pros ✅

When it comes to using TypeScript with CSS modules, the idea of generating types for class names has its merits.

Superior autocomplete

With type generation, you get superior autocomplete that functions universally without the need for extra plugins.

However, if you don't generate types, WebStorm IDE already provides autocomplete. And Visual Studio Code users, as always, can install the CSS modules plugin to have it.

Typo-Safe development

Type generation makes your development process typo-safe. It immediately throws a type error if you happen to mistype a class name. This not only helps catch errors early in your IDE but ensures these issues are reported during CI processes, providing a robust safety net.

However, if you don't generate types, wouldn't you take a look that your CSS changes have an effect anyway?

Cons ❌

New and unused code has no types generated

Webpack is a smart tool and it is good for discarding unused code. Types are not generated for the unused code, which could be confusing especially when writing new code. The code generation won't kick in until your component, that imports the CSS file is properly imported somewhere.

Delayed updates

Regenerating types and updating the IDE takes some time. While not a major hurdle, it adds a step to your development workflow.

Jump to declaration gets worse

The "jump to declaration" feature in IDEs might lead you to the TypeScript file instead of the corresponding SCSS file, which is quite annoying. I don't know how to fix this in webstorm, but VSCode has a plugin (of course).

One more webpack plugin

To enable this setup you'll need one more dependency, one more plugin in your configuration. It is also recommended to ignore watching the generated files by applying webpack.WatchIgnorePlugin. It is not a big deal, but it adds the slightest new complexity to your webpack config for the sake of generating types.

Conclusion:

So with that being said, I think the pros of types generating for CSS modules aren't really that big considering the downsides. This tooling might stand in your way sometimes, instead of making your work more productive.

Without types generating, autocomplete is OK out of the box in webstorm (and vscode has a plugin). "Typo-safety" is nice, but when working with CSS you're normally supposed to give your changes a look anyway so you'll know quickly if something went wrong, or, perhaps, you have visual regression tests that can help you out.

Of course, this all depends on your team's priorities and preferences. I, personally, really like how types help to highlight when classes are applied for no reason in code without any CSS attached to them. But I also don't like that "jump to declaration" doesn't navigate me to the CSS file in webstorm. So for smaller projects, I might prefer skipping the type generation for CSS modules.