-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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(pure): add renderOptions support to render #1333
feat(pure): add renderOptions support to render #1333
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit faba7c1:
|
3225b66
to
d5c1a9c
Compare
d5c1a9c
to
faba7c1
Compare
We should flatten this instead of allowing arbitrary options. We don't know if a passing all through will make sense. If people want to access the root options directly, they can always switch to |
how should we handle the cases where the consumer uses the non-canary version that currently does not expose those options? |
Is there something different in that regard between your initial version and the version I proposed? |
First of all, sorry for the delayed response. Afaik it's different in the sense that we base the type definitions on what the version the consumer uses, |
That's intended though, no? I don't see how type concerns need to dictate our API. It seems to me we can make flat options work. It just requires a bit more type-implementation work on our part. |
Alternate: #1354 |
Sorry I ended up not finishing this task, had some IRL things to deal with. Thanks for taking this task, I should've communicated earlier. |
What:
Why:
How:
Checklist:
docs site
closes 1297