-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Single-fetch typesafety #9893
Single-fetch typesafety #9893
Conversation
🦋 Changeset detectedLatest commit: 599ed30 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
6a43507
to
1377de4
Compare
455151f
to
e2083ad
Compare
I think that the code in this PR has the same issue as described here #9776 |
Turns out the new code with |
Let's goooo!!! Can't wait for all the goodness that will come from this PR! |
@romansndlr don't get too excited, this is just a quick patch for improved types for single-fetch in Remix, though yea that is pretty exciting on its own! The full typesafety story is coming soon in RRv7 😉 this is the first step towards that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌 great work!
For sure! I assumed as much... This is defiantly existing on it's own but also for what's to come! |
``` | ||
|
||
There are also client-side equivalents un `defineClientLoader`/`defineClientAction` that don't have the same return value restrictions because data returned from `clientLoader`/`clientAction` does not need to be serialized over the wire: | ||
Methods are also not serializable, so class instances get slimmed down to just their serializable properties: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pcattori Couldn't Remix call classInstance.toJSON()
? If it's not defined then grab the serializable properties automatically
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could but that's what json(...)
is for. The mental model for Single Fetch is that types are preserved as much as possible. We don't want a class with a bunch of serializable properties (Date
, bigint
, RegExp
, etc.) to show up as a bag of strings on the client.
These unstable functions and types were removed in remix-run/remix#9893. Since they were clearly named `unstable_` and Remix doesn't require major releases for changes to these, we'll do the same thing.
These unstable functions and types were removed in remix-run/remix#9893. Since they were clearly named `unstable_` and Remix doesn't require major releases for changes to these, we'll do the same thing.
* fix: stop re-exporting exports removed in remix 2.12.0 These unstable functions and types were removed in remix-run/remix#9893. Since they were clearly named `unstable_` and Remix doesn't require major releases for changes to these, we'll do the same thing. * chore(deps): bump to latest remix everywhere
Fixes #9428 #9514 #9649 #9714 #9776 #9834
TODO
unstable_
prefix forFuture.singleFetch
Future
re-exportsvite.config.ts
->declare module "@remix-run/server-runtime"
)