Skip to content

Conversation

@rgieseke
Copy link
Contributor

As discussed in #329

@rgieseke
Copy link
Contributor Author

On build I get

src/lib/LayerCake.svelte:204:28 This reference only captures the initial value of `yReverseValue`. Did you mean to reference it inside a closure instead?
https://svelte.dev/e/state_referenced_locally
202:   const _rNice = writable(rNice);
203:   const _xReverse = writable(xReverse);
204:   const _yReverse = writable(yReverseValue);
                                               ^
205:   const _zReverse = writable(zReverse);
206:   const _rReverse = writable(rReverse);

@rgieseke rgieseke force-pushed the svelte-5-layercake-lib branch from 8b28a9d to 960a203 Compare August 24, 2025 16:08
@rgieseke rgieseke changed the title Conver LayerCake.svelte lib to Svelte 5 Convert LayerCake.svelte lib to Svelte 5 Aug 24, 2025
@rgieseke
Copy link
Contributor Author

Maybe we can handle yReverseValue differently and then just use the derived store.

@rgieseke rgieseke marked this pull request as draft August 26, 2025 08:38
@mhkeller
Copy link
Owner

mhkeller commented Sep 1, 2025

I've never liked how the LayerCake component has all of this code for x, y, z and r even if the user hasn't defined those. It would be nice if things were more dynamic where it looked at whether those accessors were set and then created properties as a result. I'm not sure if this will work with Svelte's reactivity but just putting it out there.

@mhkeller
Copy link
Owner

mhkeller commented Sep 1, 2025

Maybe we can handle yReverseValue differently and then just use the derived store.

Ya that makes sense.

@rgieseke
Copy link
Contributor Author

rgieseke commented Sep 1, 2025

It would be nice if things were more dynamic where it looked at whether those accessors were set and then created properties as a result. I'm not sure if this will work with Svelte's reactivity but just putting it out there.

Not sure if it's possible to do everything without stores, but with or without stores maybe it's possible to be more dynamic with the context. You wrote earlier that it likely would look like chart.x etc. since it's not possibly anymore to destructure a context keys. Maybe that's an advantage for being more flexible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants