-
Notifications
You must be signed in to change notification settings - Fork 31
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
Expose LayerCake
context as slot props
#103
Comments
Interesting idea. The simplest workaround would be to make one component as the direct child of the LayerCake component and put everything in that if you want to avoid multiple components. I don’t fully get the first example with regVariables. Can you show more context. Your second example makes sense to me and I imagine doing it that way will preserve all the same variable reactivity? I wonder if there is a performance or size penalty for exposing more slot props. If you have any comparisons that would be great. I have a few other features and documentation changes on my todo list to finalize first. |
@sawyerclick just checking in on this since it seems like a good idea to implement if there's no performance hit. |
howdy! thanks for checking in. day job got busy so I haven't had the time, but I can look into this now. I'll fork and apply changes, benchmarking the perf differences. Additionally, after some thinking, I do think this approach is more appropriate. Though it does bring scalability into play if you ever added any more props/contexts. <slot xGet={$xGet} yGet={$yGet} ...> |
That sounds good. I don't mind the scalability issues – I don't foresee adding a huge amount of props in the future so having to write them all out once for this seems fine. |
And thanks for the time in testing out the changes! |
What
Expose the
LayerCake
context calculations as slot props for the<LayerCake>
component to prevent overcomplicated file structures for simple graphics.Why
I often find myself wanting to compose single-file Cakes (an un-LayeredCake, if you will), but run into the issue of needing the context's calculations and getters. If we were to expose the calculations as slot props, you'd be able to pull in repeated patterns, such as axes, while preventing the need to move every single calculation-dependent node into a component.
One example is the multi-line chart, where I wish to iterate over my data to create individual
<Line>
components directly in a<Svg>
slot, a feature-rich component already in my toolkit.How
Since stores must be declared at the top level of the component, we'd have to expose the regular variables. This would involve having to first create the variables as non-stores
or
The text was updated successfully, but these errors were encountered: