-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
feat!: align types with React Router #7319
Conversation
🦋 Changeset detectedLatest commit: 41a1647 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 |
389c5ff
to
77a8b65
Compare
@brophdawg11 I would argue that we should update RR to use Since that would be a breaking change on the RR side, I think it would be best to rename export type AppLoadContext = unknown; export type DataFunctionArgs<Context = unknown> = {
context: Context;
params: Params;
request: Request;
} Once we also updated this in RR (this should be done in a major version), we can remove it here and just re-export RR types as you wanted to do in this PR |
I'd prefer not to replace one set of duplicated types with another. If I think naming the exports the same if they aren't identical is more confusing since then FWIW we have chosen |
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.
LGTM. Only thing I think we could probably do a bit better is use unknown
for data we get from the user in AppData
, but it isn't a huge deal and would probably break some people's typechecking, so I'd say let's just leave it as any
for now.
The thing is: if we want to make it I get the idea of |
I don't have a strong preference either way really, I just would like us to be consistent on types we don't know - stuff the user hands to us somewhere and we provide back to them elsewhere - The current state is:
So do we:
Also worth keeping in mind is the much better typings coming in some of our v3 APIs, if that plays a role in how strong we try to make the v2 types. |
I'd personally go with option 2 since I think that's where we eventually want to be. |
I agree option 2 (using |
Co-authored-by: Michaël De Boey <info@michaeldeboey.be>
CI failure seems to be due to shelljs/shelljs#1133 |
Co-authored-by: Michaël De Boey <info@michaeldeboey.be>
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
Aligning types with those used in React Router to remove the confusion around
LoaderArgs
/LoaderFunctionArgs
etc.See the changeset for the details and this comment for the desired state