Alternative representation of keyed-children

[armanbilge]

another good idea from @kubukoz. Something like

Stream[IO, List[(K, Resource[IO, HTMLElement])]]

[armanbilge]

See also #84 (comment).

[hejfelix]

Just to be sure I understand: this requires key-diffing to work?

[armanbilge]

Not sure I understand :) can you explain what is "key-diffing" ?

[hejfelix]

If every value is a new key-value list, you have to find the diff of those lists to know which items are new/updated/deleted?

[armanbilge]

Oh, right! It would be based on the keys. I think of it as maintaining a sort of "key pool", where you add resources the pool based on their key. If a key already exists in the pool, you can reuse it, and if a resource sits unused in the pool, it can be cleaned up.

https://github.com/typelevel/keypool

[hejfelix]

Not sure how the current solution works, but there could be performance implications, right? I think this is something which catches react users off guard

[armanbilge]

Not sure how the current solution works

The current solution works pretty much like I described. It maintains a pool of elements, indexed by key.

Here's an example:

calico/todo-mvc/src/main/scala/todomvc/TodoMvc.scala

Line 58 in d09c652

children[Long](id => TodoItem(store.entry(id))) <-- filter.flatMap(store.ids(_))

Hosted here: https://armanbilge.github.io/calico/todomvc/index.html

If you add a large number of todo items, but only modify one of them (e.g. add/remove/check/uncheck/edit name) then performance should still be fast, since it is not rebuilding and re-rendering the list, it is performing a precise update on the modified key.

---

This issue simply proposes an alternative type signature to access that machinery.

[hejfelix]

Awesome, thanks for the explanation. Will you offer both styles?

[armanbilge]

Yes, well, your question about this issue made me rethink if we should do it.

So the current signature works with a Signal[List[K]] and a pure function K => Resource[HtmlElement]. So it is very clear that there is exactly one description of the element for key K, which is f(k), and this will never change because it is a pure function.

However, the signature proposed in that issue muddies that a bit.

Signal[List[(K, Resource[IO, HTMLElement])]]

What happens if a user updates the signal with something like:

1. List("key1" -> div(...))
2. List("key1" -> a(...))

This is highly confusing, because the same key has now been associated with two different Resource[HtmlElement]. Basically, the element for that key has changed. So should it re-render it? How does it know it should re-render it, but not re-render in some other situation?

So I'm less sure now if this is a good idea.