Using with keyed each blocks?

[jacobpake]

Looking for some advice for using this library with keyed each blocks:

<Splitpanes>
  {#each array as object (object.id)}
    <Pane>
      <InnerComponent value={object.value}/>
    </Pane>
  {/each}
</Splitpanes>

I want to change the order of the array (and resulting panes) without re-rendering the InnerComponent.

When I use the above code, the InnerComponent does not re-render (good).

Neither do the Panes (bad): the splitters act as if the Pane was in it's original position (e.g. resizing effects the wrong Pane).

[jacobpake]

To reproduce:

<script>
  import { Splitpanes, Pane } from 'svelte-splitpanes'

  let panes = [1, 3, 2]
</script>

<button on:click={() => (panes.sort(), (panes = panes))}>SORT</button>

<Splitpanes class="default-theme" style="height: 400px">
  {#each panes as pane (pane)}
    <Pane minSize={10}>
      <span>{pane}</span>
    </Pane>
  {/each}
</Splitpanes>

Click the button and then try to use the splitters on the central pane.

[orefalo]

Hi Jacob, thank you - may I ask you to compile a REPL https://svelte.dev/repl/hello-world?version=3.49.0

if i get you right it's a refresh issue, isn't it?

[Tal500]

Hi @jacobpake !

While this is a valid use case, I think no one thought about it.

We have in the library two problems:
(1) The library was designed to handle panes add and remove, but not reordering.
(2) Even in the case of panes add/removal, for simplicity the sizes of the panes get reset, and not saved.

I think we can fix (1) by checking the location of the pane element in the DOM in runtime.
But even if you check its location during the mouse dragging process, it still problematic in other parts, like the optional first splitter and a11y(planned in the future).
We need to think how we can notice that the order get changed. Maybe create a dedicated component that simulates keyed each block with some slots magic, and notify the library when the order gets changed? Maybe the Svelte afterUpdate event gets triggered when the order is changed? (which gives a simple solution)

Problem (2) should be fixed in a wider context than here. As a temporary hack, you can bind the panes size to a variable (except the last one who should be 100 - (the rest)), and then the sizes will be saved.

[Tal500]

Problem (2) should be fixed in a wider context than here. As a temporary hack, you can bind the panes size to a variable (except the last one who should be 100 - (the rest)), and then the sizes will be saved.

Update: Problem 2 was fixed by a7ab5b3 and 24ac461.

[Tal500]

We have in the library two problems: (1) The library was designed to handle panes add and remove, but not reordering. (2) Even in the case of panes add/removal, for simplicity the sizes of the panes get reset, and not saved.

I think we can fix (1) by checking the location of the pane element in the DOM in runtime. But even if you check its location during the mouse dragging process, it still problematic in other parts, like the optional first splitter and a11y(planned in the future). We need to think how we can notice that the order get changed. Maybe create a dedicated component that simulates keyed each block with some slots magic, and notify the library when the order gets changed? Maybe the Svelte afterUpdate event gets triggered when the order is changed? (which gives a simple solution)

My internal tests shows that Svelte beforeUpdate is fired in Splitpanes component when this reordering happen, so we can listen to this event and see if the panes in the DOM are in the correct order. If not, it means we need to update the internal order saved by the library.

It is much easier now to fix