pokedex.js VS return-optics

I ran a profiling tool. I searched "zz" then deleted these.

Deleting it caused a 120ms UI freeze (and I notice it :p):

Profiling report: https://share.firefox.dev/3C3OhIq

Given I had slightly more entries (a hundred more) and that I had way more node per entry, it led me with way worse performance.

Instead of a plain list I have a little summary card per pokemon (which is why I have more node per entry).

The naive implementation in Vue run flawlessly(sadly no preview):

https://github.com/Kuinox/kuinox_pokedex/

Note that the react implementation do weird thing because I tried to get around the issue without success.

Yeah? I wrote something to deal with it too (https://github.com/toastal/return-optics) 5.5 years ago. You arguably chose the wrong data as `(model, Cmd msg, Maybe extMsg)` instead of `(model, Cmd msg, List extMsg)` which would give you more flexibility and still functions as a monoid on [] instead of Nothing, but allows multiple messages shrug. I tried this approach more recently and it involved me having to encode all of actions in a massive tree and then I still had issues with certain messages including now having to UUID all elements that that previously I didn't need to think about. It was a mess, but the best I could do with the tools at hand.

If you compare this to Halogen (https://github.com/purescript-halogen/purescript-halogen/blo...) where you still have purity but can set up subscribers and listeners from any component. It's much easier to use and for some components like dialogs, it's much simpler. And this actually isn't the best example because with the latest Halogen, Portals (https://github.com/purescript-halogen/purescript-halogen/pul...) was introduced so you can launch a dialog on the spot instead of even needing to communicate between them at all.