-
Notifications
You must be signed in to change notification settings - Fork 58
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
Use the special string only for context key #1
Comments
When you consider things like "Value" feels too generic for the result of this abstraction. Does that make sense? Like, I want the resultant API to be what I would have created w/o this library, had I done it manually. <LocationSubscriber>{({ location }) => ()}</LocationSubscriber>
<GeoSubscriber>{({ geo }) => ()}</GeoSubscriber>
<MousePositionSubscriber>{({ mousePosition }) => ()}</MousePositionSubscriber> |
If we used <LocationSubscriber>{({ value:location }) => ()}</LocationSubscriber>
<GeoSubscriber>{({ value:geo }) => ()}</GeoSubscriber>
<MousePositionSubscriber>{({ value:mousePosition }) => ()}</MousePositionSubscriber> |
You should be able to name the arg whatever you want. {(location) => ()} {(pastaMaker) => ()} Why does that arg need to be an object?
|
Hmm ... I've been passing objects to render callbacks to keep a sort of symmetry with components and props, but I think you're right, the consumer can do that if they want. |
It seems like the only place we should use the special string is for the key on context, to avoid clashes with others. Everything else we can make generic.
Just seems like less docs to do it this way, no?
The text was updated successfully, but these errors were encountered: