Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃椇 Pass a bag of props to Component #9885

Open
ryanflorence opened this issue Jan 11, 2023 Discussed in #9687 · 6 comments
Open

馃椇 Pass a bag of props to Component #9885

ryanflorence opened this issue Jan 11, 2023 Discussed in #9687 · 6 comments

Comments

@ryanflorence
Copy link
Member

Discussed in #9687

  • Not just match but other stuff like navigate, location etc. (hash out what comes in there with the RFC)
  • Should be able to get full type safety since the loader/action etc. are all visible to the type system
@dbartholomae
Copy link

What can I do to move this forward? Are you open to PRs that implement this specifically?

@MichaelDeBoey
Copy link
Member

Do we still need this now that we're moving towards Component/ErrorBoundary instead of element/errorElement as of @brophdawg11's #10045?

@dbartholomae
Copy link

Based on what I see in the linked PR, I don't see a way to do something like

<Route path='/user/:userId' element={({userid}) => <UserProfile id={userid} />} />

that would have TypenScript error with Property 'userid' does not exist on type '{ userId: string; }'. How would this be achieved after the PR is merged?

@ryanflorence
Copy link
Member Author

Initially implemented by #10045 with Component prop, though no values are passed to it yet.

@ryanflorence ryanflorence changed the title 馃椇 Overload element prop with a function that receives router context values 馃椇 Pass a bag of props to Component Mar 7, 2023
@dbartholomae
Copy link

dbartholomae commented Mar 8, 2023

@ryanflorence If there is interest in something like this, I'm happy to provide a PR once #10045 is merged which either passes the params, or a bigger object containing the params to the component.
I would suggest to only pass the params, as this leads to a really nice dev experience (see example below), and I also don't see any benefit for other parameters compared to just getting them from hooks, since the route params are the only ones where type safety increases.
The main argument for passing in a more extensive object from my perspective would be to make it easier to transition from v5 to v6, or to keep the interface similar to loaders (which would mean putting the params into props.params).

Here's how I imagine the interface towards users of the library:

function UserProfile({userId}: {userId: string}) {
  return <>You are user {userId}</>
}

// This just works
<Route path='/user/:userId' Component={UserProfile} />

// This gives a TypeScript Error:
// Type '({ userId }: { userId: string; }) => Element' is not assignable to type 'ComponentType<{ userid: string; }>'.
//  Type '({ userId }: { userId: string; }) => Element' is not assignable to type 'FunctionComponent<{ userid: string; }>'.
//    Types of parameters '__0' and 'props' are incompatible.
//      Property 'userId' is missing in type '{ userid: string; }' but required in type '{ userId: string; }'
<Route path='/user/:userid' Component={UserProfile} />

@fbarbare
Copy link

I love this @dbartholomae! I personally can't think of any reason why we would need other functionalities than the URL params and the integration with the components and their props would be amazing. Being able to pass a component as prop rather than a function might also be better for re-renderings since its reference wouldn't change.
I would however still consider allowing a function to be passed as the prop value since as you said it would make it easier to transition from v5 to v6 馃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants