Skip to content
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

Closed
sawyerclick opened this issue Nov 19, 2022 · 5 comments · Fixed by #110
Closed

Expose LayerCake context as slot props #103

sawyerclick opened this issue Nov 19, 2022 · 5 comments · Fixed by #110
Labels
awaiting-merge Finished in a branch, will be included in next release enhancement New feature or request

Comments

@sawyerclick
Copy link
Contributor

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

<slot {...regContexts}>

or

<slot xGet={$xGet} yGet={$yGet} ...>
@mhkeller
Copy link
Owner

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.

@mhkeller
Copy link
Owner

mhkeller commented Dec 1, 2022

@sawyerclick just checking in on this since it seems like a good idea to implement if there's no performance hit.

@sawyerclick
Copy link
Contributor Author

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} ...>

@mhkeller mhkeller added the enhancement New feature or request label Dec 8, 2022
@mhkeller
Copy link
Owner

mhkeller commented Dec 8, 2022

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.

@mhkeller
Copy link
Owner

mhkeller commented Dec 8, 2022

And thanks for the time in testing out the changes!

@mhkeller mhkeller added the awaiting-merge Finished in a branch, will be included in next release label Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-merge Finished in a branch, will be included in next release enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants