I should note that React Router is upgrading their types and that's awesome! Some types are better than no types. However, don't miss the new tells from the list I show in here that come with it. 😜
This looks so satisfying. Sadly I'm stuck in NextJS land, but I wish they could implement something like this as well. As someone who's been a stickler to ensuring everything is type-safe in my environment, especially if it's something I can use the toolset of Zod to accomplish, this is the dream.
I don't build a lot frontend, but for backend, validation of the router you can just use a OpenAPI schema, and validate against the schema. From the OpenAPI schema, you can generate also types, when you need types. But don't trust the types, trust it with your tests, and trust the OpenAPI schema validation, for runtime validation. I validate all data is send to the API, but also what is generated, I validate the response against the OpenAPI schema. The frontend knows that it is all validated, and can use OpenAPI and the generated types. And in the backend, you know all input is validated, and you don't have to think if the value is valid. In the frontend routing, maybe we can also fis this, and also validate against a schema runtime, with e.g. AJV.
As I replied to another person on here: > OpenAPI is great and I love to use it (and proto, and swagger, and graphQL, blah blah blah). However, generated types for your API are useless if your router has no idea how to pipe them through your system. In fact, any other router you could choose right now would straight-up trash any types you give it, turning everything into an `unknown`. This just ensures that your hard-earned types and validation can make it to your leaf-node UI/UX without getting trashed.
@@tannerlinsley types are for me just a documentary helper.b my main focus is runtime, what i validate with openapi on runtime. And i check this with tests. Types are for me the latest thing to help me, nog the first focus. I always start with a test, and that is my goal to make the code work. So I witte test driven development and schema driven development. Your focus looks like type driven development. There is no good or false, just what the best works for you.
@@PieterWigboldus It's not binary. You should do both. I want both. We test our types and the runtime (via validation and testing) too. I'm not sure what you're even trying to say here any more. I'm glad you like testing, so do I, but it feels like you're trying to diminish the importance of static type-safety via justification of writing tests. That's not a safe bet by anyone's standards. Static types *are* tests (as long as you don't cheat).
@@tannerlinsley it is about the main focus. As i said, do what you like, so you trust your (or the team) code. Personally I Indeed dont do a lot with static typing, but I trust my code, not because types but because I test all the code and dont cheat there. I had team mates that go full types and cheat in the tests. Personally I only trust the runtime, and that is what I test. I also dont write a lot of frontend code, most backend and packages, so plain JS code works great there. For my packages I only add typing for other users, not for myself. But if you can just trust your code and you can easy debug it, great!
What’s with the logo? Is it like “you’re a react developer stranded on a deserted island, and all you have with you is one dependency…which dependency do you choose?”
The last thing i need is ducking types for a router which is configured once the project is initialized. How about we think about getting rid of commonjs once and for good? E Or we can finally drop npm and make a new esm package manager? Or maybe we make a new bundling tool? A proper one, not bs like webpack. Also we could resolve the federation problem and get rid of wmf shit code? No, let's make types for a router lol 😂
I should note that React Router is upgrading their types and that's awesome! Some types are better than no types. However, don't miss the new tells from the list I show in here that come with it. 😜
This is a great talk! The content is amazing. What are you using to create the slides?
@@freakantoine Keynote
Awesome job @tannerlinsley and community contributing.
Greeting from Portugal!
Tanner, you’re such a good presenter. Cried a little that you didn’t have more time 🙈
i didn't even know i needed this and now everything else is subpar
Tanner is a blessing for react
This looks so satisfying. Sadly I'm stuck in NextJS land, but I wish they could implement something like this as well. As someone who's been a stickler to ensuring everything is type-safe in my environment, especially if it's something I can use the toolset of Zod to accomplish, this is the dream.
I don't build a lot frontend, but for backend, validation of the router you can just use a OpenAPI schema, and validate against the schema.
From the OpenAPI schema, you can generate also types, when you need types.
But don't trust the types, trust it with your tests, and trust the OpenAPI schema validation, for runtime validation.
I validate all data is send to the API, but also what is generated, I validate the response against the OpenAPI schema.
The frontend knows that it is all validated, and can use OpenAPI and the generated types.
And in the backend, you know all input is validated, and you don't have to think if the value is valid.
In the frontend routing, maybe we can also fis this, and also validate against a schema runtime, with e.g. AJV.
As I replied to another person on here:
> OpenAPI is great and I love to use it (and proto, and swagger, and graphQL, blah blah blah). However, generated types for your API are useless if your router has no idea how to pipe them through your system. In fact, any other router you could choose right now would straight-up trash any types you give it, turning everything into an `unknown`.
This just ensures that your hard-earned types and validation can make it to your leaf-node UI/UX without getting trashed.
@@tannerlinsley types are for me just a documentary helper.b my main focus is runtime, what i validate with openapi on runtime.
And i check this with tests.
Types are for me the latest thing to help me, nog the first focus.
I always start with a test, and that is my goal to make the code work.
So I witte test driven development and schema driven development.
Your focus looks like type driven development.
There is no good or false, just what the best works for you.
@@PieterWigboldus It's not binary. You should do both. I want both. We test our types and the runtime (via validation and testing) too. I'm not sure what you're even trying to say here any more. I'm glad you like testing, so do I, but it feels like you're trying to diminish the importance of static type-safety via justification of writing tests. That's not a safe bet by anyone's standards. Static types *are* tests (as long as you don't cheat).
@@tannerlinsley it is about the main focus.
As i said, do what you like, so you trust your (or the team) code.
Personally I Indeed dont do a lot with static typing, but I trust my code, not because types but because I test all the code and dont cheat there.
I had team mates that go full types and cheat in the tests.
Personally I only trust the runtime, and that is what I test.
I also dont write a lot of frontend code, most backend and packages, so plain JS code works great there. For my packages I only add typing for other users, not for myself.
But if you can just trust your code and you can easy debug it, great!
What’s with the logo? Is it like “you’re a react developer stranded on a deserted island, and all you have with you is one dependency…which dependency do you choose?”
@@AvanaVana more like “just relax, we got you”
@@tannerlinsley Keeps the vacation in mind after working with React. Jk, I kinda like React after using vanilla JS for components.
im glad no one is fucking with urls except quite literally us lmao.
Im in danger😂
The last thing i need is ducking types for a router which is configured once the project is initialized.
How about we think about getting rid of commonjs once and for good?
E
Or we can finally drop npm and make a new esm package manager?
Or maybe we make a new bundling tool? A proper one, not bs like webpack.
Also we could resolve the federation problem and get rid of wmf shit code?
No, let's make types for a router lol 😂
gg, js community. Keep on making new useles frameworks everyday
@@MrJloa My priorities don’t have to be yours. That said, I look forward to watching you present your new federated, esm-only bundler soon!
You’re a dev right? Start doing those things. Do what you’re, seemingly, passionate about.
People are already building that check out JSR. Big love to you Tanner your work is amazing!
how about you start solving those issues, personally I don't like the implementation of react-router and having a different router is good
that logo with 90s vibe has to change tho
@@MerthanMerter take a hike pal, it’s great!
@@tannerlinsley if you say so, i will do it boss
I love the logo. 90s aesthetic is awesome.
@@nezudev Legendary logo