-
Notifications
You must be signed in to change notification settings - Fork 567
RFC: Context should accept non-children props as value #268
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
base: main
Are you sure you want to change the base?
Conversation
First draft of feature request
Hi @Gokul-Gireesh! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
Second Draft
Thanks for posting. I don’t think we’re likely to proceed with this change: it’s confusing. In the existing API there’s a clear, 1:1 match between the value you pass to a context provider and the value you get back out w useContext(). The proposal has a number of issues:
More fundamentally, it isn’t clear this is solving a real problem. We’re always open to exploring api changes, but in this case I don’t think we will proceed given the clear problems and lack of a strong motivation. |
Thanks for the detailed feedback. I realize I may not have fully updated the PR comment when submitting — the Value Handling Rules in my commit already clarify how I understand the concerns about implicit object creation, TypeScript typing, and whether this really solves a problem, and I see how that could add complexity. Some of the points may reflect my earlier misunderstandings, so I appreciate the clarification and the focus on keeping the API predictable and backward-compatible. |
I think there's very little value in something that's trivially easy to implement by yourself.
|
Yes but be carefull about performances here : you're recreating a new |
This RFC proposes allowing React Context to accept non-children props as the provided value.
value
for backward compatibility.value
is passed, all non-children props become the context value.children
from injection.Example:
Consumer:
const { foo, bar } = useContext(MyContext);