docs(tutorials/blog): add TS 4.9's satisfies in combination with LoaderFunction

[tom-sherman]

Closes: #

• Docs
• Tests

Testing Strategy:

I don't think this is needed as it's just a utility type. The interesting part happens in userland when we use the satisfies keyword.

---

Right now because of the way you need to add types for loaders you can get into a situation where the return type of useLoaderData is never:

const loader = () => "not a response";
const data = useLoaderData<typeof loader>();
//    ^? never

ideally we'd like typescript to error when we return the string instead of a Response. We can use the new satisfies keyword for this:

// ERROR: Type 'number' is not assignable to type 'Response'
const loader = (() => "not a response") satisfies LoaderFunction;

The loader now has a type error but it still allows for the inference of the return type to work with useLoaderData.

[changeset-bot]

⚠️ No Changeset found

Latest commit: d466256

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[remix-cla-bot]

Hi @tom-sherman,

Welcome, and thank you for contributing to Remix!

Before we consider your pull request, we ask that you sign our Contributor License Agreement (CLA). We require this only once.

You may review the CLA and sign it by adding your name to contributors.yml.

Once the CLA is signed, the CLA Signed label will be added to the pull request.

If you have already signed the CLA and received this response in error, or if you have any questions, please contact us at hello@remix.run.

Thanks!

- The Remix team

[remix-cla-bot]

Thank you for signing the Contributor License Agreement. Let's get this merged! 🥳

[tom-sherman]

Ok so the Typescript change can be reverted, I got confused because the version of remix I have doesn't have a LoaderFunction type.

@brophdawg11 do you think the docs change is valuable at all?

[brophdawg11]

yeah I think pointing out how satisfies can enhance the loader/action type safety is nice! I'm going to defer to other folks though on where the best spot for that would be. I'm also curious if we need to consider updating our create-remix templates to use TS 4.9+ if we're going to start recommending those features, or if we can just be clear in our docs that it requires you be on a new enough version of TS.

[sergiodxa]

Question, can you use satisfies without arrow functions?

[brophdawg11]

@tom-sherman actually, since you can technically return anything (type AppData = any) - does satisfies even help in that case? It might be something where it only helps if you define a more narrowly-typed loader function on your own?

[tom-sherman]

@sergiodxa Unfortunately not, it appears the syntax doesn't support it right now - you can only use satisfies with an expression.

@brophdawg11 Oh you're absolutely right 🤦 in which case I don't think this even deserves a place in the docs. It might make sense as a more editorialised blog post I guess (I'm already writing one on my own blog)

[tom-sherman]

@sergiodxa A workaround is something like this:

type Fn = () => number;

function foo() { return "ds" }

foo satisfies Fn; // type error

Not recommended tho because compilers will likely output a foo; statement.

[pcattori]

@sergiodxa A workaround is something like this:

type Fn = () => number;

function foo() { return "ds" }

foo satisfies Fn; // type error

Not recommended tho because compilers will likely output a foo; statement.

One function-compatible option is:

(function hello() {
    return "world"
}) satisfies () => number;

[pcattori]

We're already working on upgrading esbuild to 0.15.13 for satisfies support. You can check #4639 for progress on that.

[pcattori]

@tom-sherman actually, since you can technically return anything (type AppData = any) - does satisfies even help in that case? It might be something where it only helps if you define a more narrowly-typed loader function on your own?

There's still value in using satisfies even then since it will make sure the function params are correct for example.

[tom-sherman]

One function-compatible option is:

(function hello() {
    return "world"
}) satisfies () => number;

@pcattori that's a function expression/anonymous function though. You can't do this for example

export (function hello() {
    return "world"
}) satisfies () => number;

[pcattori]

@pcattori that's a function expression/anonymous function though. You can't do this for example

export (function hello() {
    return "world"
}) satisfies () => number;

Yea, if you want (1) export on the same line as the definition and (2) to use satisfies, then I don't think there's a way to do it with a named function.

The only way would be:

export const hello = (function () {
    return "world"
}) satisfies () => number;

but the main benefit of named functions is that they can be referenced before their definition, which you would lose out on with this^.

Personally, I prefer to use arrow functions, but yes its unfortunate for those who use function that satisfies is not supported better for it AFAIK.

[tom-sherman]

Btw, shameless plug 😅 https://tom-sherman.com/blog/remix-typescript-satisfies

[pcattori]

https://tom-sherman.com/blog/remix-typescript-satisfies

FYI we export a LoaderFunction type from @remix-run/node (and the other runtime packages too), so you can use that instead of defining Loader yourself: satisfies LoaderFunction

I guess you already knew that since this PR uses LoaderFunction in the docs 😅

[pcattori]

Looks like tests are failing because the markdown plugin for eslint can't parse TS 4.9 satisfies.

Possible solution: eslint/eslint-plugin-markdown#114 (comment)

[tom-sherman]

I guess you already knew that since this PR uses LoaderFunction in the docs 😅

@pcattori Weird one, I wasn't actually aware of that type when I wrote the blog because I'm on an experimental channel (deffered) that doesn't have that type 😆

[moishinetzer]

Is there any updated best practice/solution to solve this?

I want to be able to take advantage of useLoaderData<typeof loader>() AND make sure that my loader functions return the correct types.

[tom-sherman]

@moishinetzer The simplest way to do that would be to add a return type annotation to the loader eg.

export async function loader({ context }: LoaderArgs): Promise<TypedResponse<{ posts: Post[], tags: string[] }>> {
  const blog = new BlogData(context);

  const [posts, tags] = await Promise.all([
    blog.listAllPosts(),
    blog.listAllTags(),
  ]);

  return json({
    posts,
    tags,
  });
}

const { posts, tags } = useLoaderData<typeof loader>();

You can use satisfies if you wanted to assert a partial data shape at the loader level and have the concrete return type inferred. I touch on this in my blog post.

[machour]

@tom-sherman Could you rebase this to target main?
Documentation & templates updates go directly to main

[MichaelDeBoey]

Suggested change

	```ts filename=app/routes/posts/index.tsx lines=[1,23]
	```ts filename=app/routes/posts/index.tsx

[MichaelDeBoey]

Suggested change

	import type { LoaderFunction } from "@remix-run/node";
	import { json } from "@remix-run/node";
	import type { LoaderFunction } from "@remix-run/node"; // or cloudflare/deno
	import { json } from "@remix-run/node"; // or cloudflare/deno

[pcattori]

Looks like the upstream issues with eslint plugins and TS 4.9 have been resolved as yarn lint passes locally for me with the suggested edits.

That said, we are no longer using this tutorial in the v2 docs, so closing this PR.