8000 Migrate to Runes · Issue #156 · mhkeller/layercake · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Migrate to Runes #156

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.

Si 8000 gn up for GitHub

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

Jump to bottom
Open
saabi opened this issue Dec 26, 2023 · 10 comments
Open

Migrate to Runes #156

saabi opened this issue Dec 26, 2023 · 10 comments
Assignees
@mhkeller
Labels
advisory Notice of something

Comments

@saabi
Copy link
saabi commented Dec 26, 2023 •
edited by mhkeller
Loading

After attempting to port a working Svelte 3/LayerCake app (using npm i -S --force LayerCake) I got the error above (ERR_SVELTE_TOO_MANY_UPDATES).

To verify the bug wasn't on my side, I moved an arbitrary working LayerCake REPL example to the Svelte 5 Preview REPL and I get the same error:

playground:output:801 Uncaught Error: ERR_SVELTE_TOO_MANY_UPDATES: Maximum update depth exceeded. This can happen when a reactive block or effect repeatedly sets a new value. Svelte limits the number of nested updates to prevent infinite loops.
    at infinite_loop_guard (playground:output:801:10)
    at flush_queued_effects (playground:output:818:4)
    at process_microtask (playground:output:845:3)

Working REPL Example: https://svelte.dev/repl/ad32f9f301484d0cace82272126e9d09?version=3.46.2
Svelte 5 REPL Example (failing)
@mhkeller
Copy link
Owner

Thanks for letting me know. I’m waiting for the full Svelte 5 release before figuring out what form LayerCake takes. Given that the library is a collection of stores and stores are no more, it will mean a significant rewrite.

@saabi
Copy link
Author
saabi commented Dec 29, 2023

I may be able to help out with that... I do dataviz, performance and low level for a living. Check out https://github.com/nestauk/svizzle It doesn't use LayerCake (yet) but a port is planned.

It will have to wait for a new LayerCake release however.

@mhkeller
Copy link
Owner

Great – thanks for the offer! The first approach I plan on trying will be to replace every store with a $state rune and then instead of derived stores, use $derived. I haven't seen any examples on how runes interact with contexts, though.

Slots are also deprecated so there will have to be some changes there, too. It looks like the existing syntax may work if layout components render a children snippet.

But since Svelte 5 is still a moving target, I think it's better to wait until it settles.

@mhkeller mhkeller changed the title LayerCake on Svelte 5 fails with ERR_SVELTE_TOO_MANY_UPDATES Update to Svelte 5 Dec 29, 2023
@rgieseke rgieseke mentioned this issue Jan 23, 2024
Closed
@mhkeller mhkeller added the awaiting-something-else Needs some other thing to happen before it can be done label Feb 10, 2024
@mhkeller mhkeller self-assigned this Feb 10, 2024
@mhkeller mhkeller changed the title Update to Svelte 5 Update to Svelte 5 when it's released Feb 10, 2024
@mhkeller
Copy link
Owner
mhkeller commented May 3, 2024 •
edited
Loading

There's a PR for making this compatible with Svelte 5. I may merge it or may wait until 5.0.0 is out: #190

edit: this has been merged and the library is compatible with Svelte 5

@mhkeller
Copy link
Owner
mhkeller commented May 3, 2024 •
edited
Loading

FYI the existing LayerCake library works out of the box in Svelte 5 projects. That PR clears up some peerDependency warnings.

Eventually I will port LayerCake to using runes but it will require changes to component API. Using $state runes, you can no longer destructure values from contexts like you can with stores

import { getContext } from 'svelte';
const { xGet, yGet } = getContext('LayerCake');

// becomes...

const chart = getContext('LayerCake')
chart.xGet
chart.yGet

I may include a helper so you're not interacting with getContext directly

import { LayerCake, Svg, getChart } from 'layercake';

const c = getChart();

c.xGet
c.YGet

The design is still TBD but that approach seems to help with the ergonomics. Feedback welcome.

@mhkeller mhkeller changed the title Update to Svelte 5 when it's released Migrate to Runes May 9, 2024
@mhkeller
Copy link
Owner
mhkeller commented May 9, 2024

A note on the timing for this: Since the library is compatible with Svelte 4 and 5 but a migration to runes will cut off support for anything less than Svelte 5, I'm not in a huge rush to do that. It may make most sense to wait for something like Svelte 6 when some of the features Layer Cake uses become deprecated.

The goal here being that it works for the largest number of people.

@mhkeller
Copy link
Owner

This PR will update the library to Svelte 5 now that 5.0.0 is released: #242

@mhkeller mhkeller added advisory Notice of something and removed awaiting-something-else Needs some other thing to happen before it can be done labels Oct 19, 2024
@mhkeller mhkeller mentioned this issue Jan 24, 2025
Open
@rgieseke
Copy link
Contributor

I'm curious whether you had a chance to think more about Layer Cake and Svelte 5. I'm wondering whether it would make sense to move forward to Svelte 5. Layer Cake is fairly small so people with legacy projects could continue with an old version.

In a Svelte 5 project I find the switching between the different modes confusing when I use Layer Cake old-style components.
Would it make sense to start with porting these first?

I am happy to help with anything that might help with that, be it finishing the TypeScript additions (#218) or improved testing (#244).

@mhkeller
Copy link
Owner

Thanks for the help! I feel like there are a few sub-projects with this

  1. Update the examples and components to using runes
    1. This is probably a good place to start but it would be nice if the website kept a reference to the old style. Maybe the number of people still using that is really small but it would be nice to not make it super hard to find those references for those in need
  2. Update the website's inner-workings to use runes
    1. Seeing as some of that code is six years old and rather complex (I borrowed from the original Sapper website documentation) there may be some tricky things. Or maybe it will be fine
  3. Write tests for rendered components (#244). This is needed before step 4
  4. Update the library itself to use runes, which in turn will necessitate updating the examples to use the const c = getContext('LayerCake') syntax

So, one approach would be start with 3, then do 4 and then 1 and 2. Because I don't yet know exactly what the best new API will be for runes, I'm inclined to do the steps in the order listed above, which provides the quickest path for users to move away from the old-style Svelte syntax.

To turn this post into something actionable, I would say that the two issues you pointed out, #218 and #244 are good ones to start with. As I think about it, I'm not sure that 1i is really necessary. Maybe it's fine if we just migrate all of the examples on the site to runes. Here's an issue for that #255.

@rgieseke rgieseke mentioned this issue Mar 14, 2025
Closed
@rgieseke
Copy link
Contributor

The website's inner workings (2) need to be updated before the components are converted (1), as Svelte 5 components cause errors when run with the current website. I guess 2, 3 (and then 1) can go on step by step and then 4 whenever it's a good time.
In any case, with Svelte-Migrate now being able to convert Layer Cake components without losing all docstrings it's possible to just drop old-style Layer Cake components in a new Svelte 5 project, convert them and not have to switch between styles.

@rgieseke rgieseke mentioned this issue Apr 22, 2025
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mhkeller mhkeller

Labels
advisory Notice of something
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rgieseke @mhkeller @saabi
0