Re: [whatwg/dom] Add convenient, ergonomic, performant API for sorting siblings (#586)

I am surprised react keys are not known today, but [this is the documentation about it](https://reactjs.org/docs/lists-and-keys.html#keys).

Ported to this `reorderChildren` idea, let's take a basic list as example:

```html
<ul id="list">
  <li data-order="2">b</li>
  <li data-order="1">a</li>
  <li data-order="3">c</li>
</ul>
```

If I understood correctly what's being proposed, a `list.reorderChildren("data-order")` would produce the following output:

```html
<ul id="list">
  <li data-order="1">a</li>
  <li data-order="2">b</li>
  <li data-order="3">c</li>
</ul>
```

and every single `<LI>` element in the list is preserved, meaning the second `<li data-order="1">a</li>` in the initial list, will be exactly the same `<li data-order="1">a</li>` found as first element child of the `list`, so if that's the case, we're having the very same behavior keys in React are meant to bring: same node per reference.

Let's see a swap nodes, using the *keys* as extra approach:

```html
<ul id="list">
  <li data-order="1" key="a-key">a</li>
  <li data-order="2" key="b-key">b</li>
  <li data-order="3" key="c-key">c</li>
</ul>
```

Now swapping 1 with 3 would preserve the node identity and the JS would be like:

```js
list.firstElementChild.dataset.order = 3;
list.lastElementChild.dataset.order = 1;
list.reorderChildren("data-order");
```

Now we have preserved identity and a way to **diff** a previous state with the current one, where some node got prioritized or de-prioritized but all of them have kept their references.

This is an extremely limited way to deal with the potential of a diffing *previous-next* API that could not only order by all means, not just numerically for attributes that also are always **strings** on the DOM, but it could take into account new node either inserted or removed at a specific index of the list, so that such API would cover every single possible use case out there, instead of requiring effort to cover only numerical sort out of strings, avoiding possible growing and shrinking lists to benefit from such API (a TODO list is already a good example of that, as state).

I hope this explains better why this API would have 1% of the potential it could have if it would instead just diff the passed along list of nodes as iterable that could benefit from any sorting method, not just numeric, and avoid tons of boilerplates for libraries authors to deal with just the number, as that requires a "*keep in sync*" attributes with diffing for an API that, as presented, already takes care of diffing previous nodes with the new ordered one.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/586#issuecomment-1416305593
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/586/1416305593@github.com>