[labs/context] Add provideHelper for use with isolated components #3736
Conversation
🦋 Changeset detectedLatest commit: cb7aeaa The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
rictic
left a comment
There was a problem hiding this comment.
This is cool, seems very useful for storybook code and other cases where an element that usually has a custom element ancestor is rendered without one.
Please add a few tests
| * from the parent that provides the context. | ||
| * | ||
| * This helper provides static values for the specified contexts. It does | ||
| * not support updates via subscribe. |
There was a problem hiding this comment.
This doc is missing some important context I think. What actually is this function? How do you use it?
| * This helper provides static values for the specified contexts. It does | ||
| * not support updates via subscribe. | ||
| */ | ||
| export const provideHelper = (params: {[key: string]: unknown}) => { |
There was a problem hiding this comment.
Here and elsewhere, the term "helper" is overly generic, like "util" or "meta." This does look like a helpful function, but most good functions are helpful, so naming it a helper doesn't aid the reader in understanding how it's helpful, or in what situations.
Consider a name that communicates more. If I understand this right, I think staticProvideHandler is one candidate. static because it provides a constant value, and handler because it's used as an event handler.
There was a problem hiding this comment.
I would consider:
providerListener()because they're event listeners, and this is a factory for making listeners that are providers.contextProvider()though it's a little generic compared to other ways of providing, it reads ok at the use site.contextListener()which might seem generic on the provide vs consume side, but only providers actually listen for events, while consumers fire them.
There was a problem hiding this comment.
Ah yeah, +1 to listener instead of handler.
Of those, contextProvider is my fave, followed by providerListener. I think provide is so key to what's happening that it needs to be in the name.
This provides a
provideHelpermethod that you can use in cases where your component is isolated from the parent element that provides the context. Some examples here are unit tests, or in Storybook.