table
table copied to clipboard
feat: svelte 5 adapter
Overhauls the Svelte adapter so that it's compatible with Svelte 5.
Some overview of the work that was done:
- All dependencies on
svelte/internal
are removed. -
createSvelteTable
now returns a signal in lieu of a store. According to @dummdidumm, Stores may eventually be deprecated. - The
flexRender
API is now replaced with a more idiomaticFlexRender
component. -
FlexRender
employs the use of Svelte 5's new Snippet feature - it made this adapter way simpler. - Typescript typing is more robust than it was before
- All user-facing code that's not being carried over from the core library is documented.
Feedback welcome.
solves #5213
The createSvelteTable
function needs a bit more work. It's not very efficient at the moment. I've marked as draft while I work on this.
This is looking good.
@wlockiv @niemyjski @dummdidumm I've been consulting with some of the other TanStack maintainers, and we think it should actually be possible to keep backwards functionality with Svelte 3/4. If it's possible to have this adapter work with Svelte 3-5, we need to try that.
This is pretty tricky, and I'll do my best to catch up on the Svelte snippet stuff. Was there a different way that the original svelte adapter could have been using flexRender without Svelte internal?
Are you saying that there should be no breaking change at all, or that there can be breaking changes, but it should also work with Svelte 3/4? It should be possible to have it work 3-5 with a breaking change (the FlexRender
component) by keeping the store API ($table.get...
instead of table.get...
), but it will not be possible to achieve that keeping the same API. That's because the current API passes the everything to <svelte:component this={..} />
, which means it needs to augment a component on the fly, which is not possible to keep compatible across 3/4 and 5.
What's the reasoning behind the decision?
Are you saying that there should be no breaking change at all, or that there can be breaking changes, but it should also work with Svelte 3/4?
There can be breaking changes with flexRender. From what I see, that seems unavoidable.
But we should try our best to have the adapter work with Svelte 3-5. From our understanding, Svelte 5 is supposed to mostly be backwards compatible. I think the expectation is that TanStack Svelte Table should work in each Svelte version.
If this doesn't seem possible, we can keep going forward with Svelte 5 only. I just don't know how long the Svelte ecosystem is going to take for that to be the go-to.
In this case it should be possible to support 3-5 in one, if the store style API is kept. What is the idea behind supporting 3-5 if there's a breaking change anyway? The thought that adoption for 5 is gonna take a while so it's better to have one small breaking change and then another one in like half a year when switching towards an API that leverages Svelte 5 capabilities?
@dummdidumm How much more efficient is the Svelte 5 way of doing things in terms of performance? Is it large?
āļø Nx Cloud Report
CI is running/has finished running commands for commit 91f6f835fd239c34485ac2642c95a729d7352ee2. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.
š See all runs for this CI Pipeline Execution
ā Successfully ran 1 target
Sent with š from NxCloud.
Just pointing out that Svelte 5 isn't released yet, so this PR shouldn't be merged before that.
On another note, would it be reasonable to maintain 2 adapters instead? One for Svelte 3/4 and one for Svelte 5.
I really donāt see why we canāt have multiple releases or packages. yes, we should push a package asap as Iām and others are blocked from even upgrading to svelte 5 unless we drop tan stackā¦ we canāt give feedback easily.Sent from my iPhoneOn Mar 21, 2024, at 12:14āÆPM, sledgehammer999 @.***> wrote:ļ»æ Just pointing out that Svelte 5 isn't released yet, so this PR shouldn't be merged before that. On another note, would it be reasonable to maintain 2 adapters instead? One for Svelte 3/4 and one for Svelte 5.
āReply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
Just pointing out that Svelte 5 isn't released yet, so this PR shouldn't be merged before that.
Yeah, we will not just remove Svelte 3/4 support. Especially while Svelte 5 is a beta.
On another note, would it be reasonable to maintain 2 adapters instead? One for Svelte 3/4 and one for Svelte 5.
I was originally against this because of how messy it seemed. But it might be the best way forward.
I can see table having "svelte-runes", or "vue-vapor", etc. adapters.
An issue that we would run into, however, is how to install multiple versions of Svelte in the TanStack Table replo. Probably possible with pnpm, just need to look into it.
@lachlancollins was telling me if should absolutely be possible to support Svelte 3-5 in one adapter though. I just don't know how to get that to work with flexRender, unless we just deprecate that in the current adapter.
I'd just keep it simple, create a new package with preview suffix targeting 5.0, can move those bits to the old package once released and bump major. If users need to stay on the old svelte 3-4, don't upgrade to a new major. Also, could just have multiple branches each with different versions / releases with same package name?
@dummdidumm How much more efficient is the Svelte 5 way of doing things in terms of performance? Is it large?
Imo, it's going to be pretty negligible. At least for state management. The state management layer between Svelte (3/4 or this 5 adapter) is pretty thin. There may even be some ways that observables (from Sv 3/5) integrate w/ @tanstack/table a little more intuitively than signals.
Just pointing out that Svelte 5 isn't released yet, so this PR shouldn't be merged before that.
On another note, would it be reasonable to maintain 2 adapters instead? One for Svelte 3/4 and one for Svelte 5.
I know this is more of a question for the maintainers, but I am afraid I won't have the margins to help out with an adapter that's available across the major versions (3-5) anytime soon. Assuming someone else doesn't pick that up, 2 adapters would probably mean Svelte 5 compatibility comes sooner for folks who are testing it out.
I'm also not opposed to publishing it myself as an "unofficial community adapter" of sorts.
Also also - the new, easier programmatic rendering made available in Svelte 5 makes the adapter less of an "adapter" and more of an "implementation" if that makes sense. What I mean is - It's simple enough to just be a documented implementation tbh.
yes, we should push a package asap as Iām and others are blocked from even upgrading to svelte 5 unless we drop tan stackā¦
I totally understand your frustration, and it's why I started working on this PR. I'm excited to see this available to other svelters. But if this is a blocker for your project, then it's possible to use this adapter before this PR is merged.
This new adapter is actually really really tiny, straightforward, and, at least for the time being, you could easily drop its code into your existing project. I basically built the adapter in a SvelteKit project, then copy-pasted it into this codebase. I don't see any reason you wouldn't be able to do the same, assuming there aren't any breaking releases from Svelte 5 since the version I developed on.
@niemyjski
I really donāt see why we canāt have multiple releases or packages. yes, we should push a package asap as Iām and others are blocked from even upgrading to svelte 5 unless we drop tan stackā¦
TanStack Table should NOT be a blocker for your team at all. You can just install Table core and make your own Svelte adapter. Copy it from this PR even. This is always an option.
I don't think two adapters will help much. Supporting 3-5 should be possible if it's ok to have a breaking change to use the FlexRender component introduced in this PR. If so, then the store API can be reintroduced. Once Svelte 5 is stable another major could be released to switch over from store API to runes API (basically this PR). That way the newest version of the adapter works for Svelte 5 and takes advantage of its new features, while the previous version will work for everyone using Svelte 3/4, too.
@dummdidumm i noticed that release 85 of svelte 5 has a breaking update to effect.pre
, which we use here. Does that update affect us?
No
Looks like there are conflicts in this pr.
I can't provide any feedback as pr was closed but was also seeing:
not sure if any is banned in this project but I'm getting errors source importing and trying out.
Argument of type 'HeaderContext<TData, TValue> | CellContext<TData, TValue>' is not assignable to parameter of type 'HeaderContext<TData, TValue> & CellContext<TData, TValue>'. Type 'HeaderContext<TData, TValue>' is not assignable to type 'HeaderContext<TData, TValue> & CellContext<TData, TValue>'. Type 'HeaderContext<TData, TValue>' is missing the following properties from type 'CellContext<TData, TValue>': cell, getValue, renderValue, row
Feels like the typing here should be inferred from the context, I'm trying to simplify. I'm in the process of trying it out by converting: https://github.com/exceptionless/Exceptionless/blob/main/src/Exceptionless.Web/ClientApp/src/lib/components/data-table/data-table-body.svelte#L44
@niemyjski Sorry that was on accident. It's open again.
I can't provide any feedback as pr was closed but was also seeing:
not sure if any is banned in this project but I'm getting errors source importing and trying out.
Argument of type 'HeaderContext<TData, TValue> | CellContext<TData, TValue>' is not assignable to parameter of type 'HeaderContext<TData, TValue> & CellContext<TData, TValue>'. Type 'HeaderContext<TData, TValue>' is not assignable to type 'HeaderContext<TData, TValue> & CellContext<TData, TValue>'. Type 'HeaderContext<TData, TValue>' is missing the following properties from type 'CellContext<TData, TValue>': cell, getValue, renderValue, row
Feels like the typing here should be inferred from the context, I'm trying to simplify. I'm in the process of trying it out by converting: https://github.com/exceptionless/Exceptionless/blob/main/src/Exceptionless.Web/ClientApp/src/lib/components/data-table/data-table-body.svelte#L44
See this diff.
This narrows the type of content based on context. Not saying it's perfect, but without a minimal repro of the issue it's difficult for me to understand and address your specific case.
Hey @KevinVandy - may we re-open this discussion in anticipation of v5's official release? We discussed some options on releasing the adapter earlier:
- Releasing a new, separate Svelte5 adapter package so Svelte4 compatibility is still maintained via the original (existing) adapter package, or
- Replacing the existing Svelte4 adapter with this one alongside the next major version (v9) of
table
, or - Not releasing this adapter, but instead adding documentation to inform users how to implement TanStack Table in Svelte 5 without the existing package, or
- Releasing this adapter separately as a "community adapter" until introducing this breaking update to
svelte-table
is less detrimental.
My vote is just to replace it, use the current version if you need 4.x
We can go ahead and merge this into the alpha branch soon, but the documentation for svelte state and adapter needs to be updated with this.
I'll try and work on it this weekend.
Hi, I know that v9 is still an alpha, however I am already using it with Svelte 5. Would it be possible to push a new release tag to have a more up to date version of the alpha available for npm?
The next large alpha release will be in a couple weeks probably
Gotcha, thanks for the reply.I was asking because the examples (for svelte) in the latest alpha branch commit are not compatible with alpha 9, so I don't know exactly what I should use.