Svelte 5 support: ERROR: No matching export in "a" for import "b" about table HOT 32 OPEN

I've drafted up an approach using the vanilla library.

Repo: https://github.com/wlockiv/svelte5-tanstack-table-demo
Demo: https://adorable-beijinho-47e52b.netlify.app/

This gives us a <RenderCell cell={cellContext} /> component, a <RenderHeader header={headerContext} />, and another for footer that is basically just a wrapper of header... haven't touched placeholder yet. But I'd be interested to hear thoughts.

from table.

Svelte maintainer here - I won't have time to work on this but if you have questions regarding the new APIs I'm happy to help. Also note that it's probably wise to wait a few more weeks until things have stabilize a bit more.

Our plan was to wait for Svelte 5 to get to beta at least. @Mokshit06 created the original Svelte 3 adapter. Maybe will be able to help again?

from table.

Thanks @KevinVandy for the ping.

@dummdidumm The idea to keep inline wrapper component logic was for mainly 2 reasons:

• In most cases the the cell to be rendered is either a static string (when it's for cell headers), or a string that can be computed or accessed from table info. In these cases it's much more intuitive to just be able to write these in the table definition (as shown below) than create components for them.

  const defaultColumns: ColumnDef<Person>[] = [
    {
      accessorKey: 'firstName',
      header: 'First Name', // static string
      cell: info => info.getValue(), // computed string
      footer: FooterComponent // svelte component
    }
  ]

• In addition to this we need to support svelte components as these cells as well, so returning the reference from flexRender wouldn't be enough.

Ideally we would want to support both these use cases.

It would be helpful if svelte had a way to mount components at runtime or create instances of them outside of svelte tree, but I can see why would require a lot more work on the svelte team's side and it might not be deemed worth the effort.

I am open to suggestions on how this can be improved on TanStack Table's end though so that future svelte internal versions don't cause issues.

from table.

@KevinVandy yep I do. I went on vacation and left the laptop.

Yep I can do that when I get back I think. Thank you for taking a look at the repo!

from table.

Seems like the culprit is these libraries are depending on 'svelte/internal' which has breaking changes and is not backwards compatible.

from table.

Which internal APIs is Tanstack Svelte relying on and why?

from table.

The Svelte adapter has to be rewritten/overhauled to work with Svelte 5. Who wants to help?

from table.

Svelte maintainer here - I won't have time to work on this but if you have questions regarding the new APIs I'm happy to help. Also note that it's probably wise to wait a few more weeks until things have stabilize a bit more.

from table.

@dummdidumm If this library supports 4x currently and 5x has backwards compatibility. I don't get why you recommend waiting until 5 is stable since this library shouldn't be using internal svelte apis, nothing should break...

from table.

@KevinVandy @dummdidumm If this library supports 4x currently and 5x has backwards compatibility. I don't get why you recommend waiting until 5 is stable since this library shouldn't be using internal svelte apis, nothing should break...

We were using internal Svelte APIs a lot. Happy to see other approaches for rendering custom Svelte components inline though.

from table.

Happy to see other approaches for rendering custom Svelte components inline though.

@KevinVandy sorry for hijacking but since (at some point) you're going to rework the svelte adapter, I want to bring to your attention #4962 too.

from table.

@sledgehammer999 I'm guessing that the use of flexRender in svelte is just inefficient in general. Unless the new internal svelte 5 apis might have some improvements.

from table.

You lost me at internal, which is why this issue is open. Seems like the svelte team should add some public lifecycle helpers / renders for components. Thinking snippets could help.

from table.

You lost me at internal, which is why this issue is open. Seems like the svelte team should add some public lifecycle helpers / renders for components. Thinking snippets could help.

The adapter isn't that big. Anyone can see it here down below.

https://github.com/KevinVandy/tanstack-table/blob/main/packages/svelte-table/src/index.ts

https://github.com/KevinVandy/tanstack-table/blob/main/packages/svelte-table/src/render-component.ts

This will have to be completely rewritten to work with Svelte 5. As far as I know, Svelte application code will mostly have backwards compatibility, but use of the internals will not. So these breaking changes are not unexpected.

from table.

If you look at the linked issue svelte team will break internal apis in revisions if necessary. As such the adapter would be much more stable if we came up with exactly what we need or perhaps better if the svelte team writes the adapter so they can see pain points.

from table.

Agreed. I'd be happy if you or another Svelte expert did that for us

from table.

RC coming before march (via https://syntax.fm/show/723/svelte-5-speed-simplicity-and-size) would be great to figure out what public api's would make this possible so this project doesn't need to consume internal api's

from table.

RC coming before march (via https://syntax.fm/show/723/svelte-5-speed-simplicity-and-size) would be great to figure out what public api's would make this possible so this project doesn't need to consume internal api's

If there is a way to define components in line for custom cell, header, etc. renders, and a way to call a function (flexRender) that can render inline Svelte components both client-side and sever-side, then I think we'll be set. Otherwise, we might not be able to support that functionality anymore.

from table.

Could you explain why the inline wrapper component logic is necessary? i.e. why can't you directly return a reference of Placeholder.svelte from flexRender?
Edit: Is it to avoid the need for passing the props separately? i.e. so you can do <svelte:element this={flexRender(..)} /> instead of something like <svelte:element this={flexRender(..)} {...flexRenderProps(..)} />?

from table.

Can we get some response to the question above. Also, if anyone has any bandwidth would be good to start on this now that svelte 5 is much further along.

from table.

Hey everyone, the Svelte adapter was provided by the Svelte community. I'm not that knowledgeable with Svelte myself anymore. A Svelte 5 adapter will need to be provided by the community again for best results.

from table.

@Mokshit06 was a valuable contributor to the original adapter. Maybe they can weigh in here.

from table.

Eagerly waiting for this issue to be resolved.

I also agree that flexRender is not Svelte-esque.

from table.

Eagerly waiting for this issue to be resolved.

I also agree that flexRender is not Svelte-esque.

What would be a more Svelte compatible way to add markup to cells and headers in the column definitions? Or should we just remove that capability altogether and just expect Svelte devs to add a lot of if blocks in the cell components?

from table.

Do we like the way that svelte-headless-table has accomplished this? Tbh the column defn system doesn't feel that different to me, but It looks like he uses svelte-render, which he built, to render components though.

from table.

Having a RenderCell component that you pass the column definition sounds like a nice way to do this without reaching into internals - although svelte-render is sadly to break, too, since it's extending the class, and in Svelte 5 components are no longer classes.

from table.

Thinking out loud, why couldn't each cell be a svelte snippet?

from table.

I like the idea - this would basically let Svelte do all the if blocks that @KevinVandy was mentioning, right? I've only read some of the docs for snippets, so I'm curious how would this look?

Something like:

Plain Text Cells

<script>
    const exampleColDefn = [{
        accessorKey: 'createdAt',
        accessorFn: (data) => new Date(data.createdAt).toLocaleDateString(),
        header: 'Date Added',
        enableGrouping: false
    }]

    const table = // create the tanstack table...
</script>

{#snippet cellSnippet(cell)}
	<div>{cell.getValue()}</div>
{/snippet}

{#each $table.getRowModel().rows as row (row.id)}
    {#each row.getVisibleCells() as cell (cell.id)}
        {@render cellSnippet(cell)}
    {/each}
{/each}

Component Cells

<script>
    const exampleColDefn = [{
        accessorKey: 'createdAt',
        accessorFn: (data) => new Date(data.createdAt).toLocaleDateString(),
        cell: (ctx) =>
            renderComponent(DataTableCell, {
                data: ctx.getValue()
            }),
        header: 'Date Added',
        enableGrouping: false
    }]

    const table = // create the tanstack table...
</script>

{#snippet cellSnippet(cell)}
        <svelte:component this={flexRender(cell.column.columnDef.cell, cell.getContext())} />
{/snippet}

{#each $table.getRowModel().rows as row (row.id)}
    {#each row.getVisibleCells() as cell (cell.id)}
        {@render cellSnippet(cell)}
    {/each}
{/each}

If my explanation seems unclear, it's because I'm still familiarizing myself with how TanStack Table works, and I'm also not very knowledgeable about how snippets work either. So, I ask for your understanding regarding my syntax errors as we delve into this concept. 🫠

from table.

Yeah, I like the idea of a RenderCell too. Whose up for making a PR for an official Svelte 5 adapter?

from table.

Sorry I didn't realize before that Placeholder in the adapter has nothing to do with placeholders in the core library. I should be good to make this into a PR here then...

from table.

@wlockiv Didn't know if you were going to make a PR for your adapter or not.

Took a look at your repos. Do you think it would be best to just have 1 <FlexRender content={cell.column.columnDef.cell} context={cell.getContext()} /> util component instead of RenderCell, RenderHeader, etc.? Seems more consistent with the other adapters.

from table.

Svelte RC is out :)

from table.