Solid: I got some issues with updating attributes

[ts-thomas]

For some reason I could not get updating attributes working.

Here is the implementation and the exported function: https://github.com/nextapps-de/mikado/blob/master/bench/test/solid/src/main.jsx#L6

Here is the method which calls this exported function (along with passed data): https://github.com/nextapps-de/mikado/blob/master/bench/test/solid/index.html#L15l

All tests runs fine, but the "update" test is not working which basically looks like items[0].title = items[50].title for example. It did not refresh the UI. Do I miss something?

[ryansolid]

Yeah, there were some changes to the binding system between version 0.9.3 and version 0.13.0. I think you are best served using the newer one since there is no strangeness around {( )}. Basically the field isn't set to be dynamic using the older version. However, it is possible now to do less optimal things easier from a benchmark perspective.

I can help you write different version for the different versions if you'd like. Solid is data-driven by default but supports explicit keyed and node re-use if necessary through the reconcile method. It should be pretty straight forward, ~I just need to understand which data fields can change, and which will never change. It makes a difference in libraries like Solid to know the requirements of the template of what can change and what will never change.~

EDIT: nvm found it https://github.com/nextapps-de/mikado/blob/master/bench/bench.js#L642

I also notice you have the update as failed for Surplus, Knockout, and Sinuous for Data Driven which is ironically their forte, ie the reason people use such libraries. I suspect the same would be true for Solid out of the box. Is it that they aren't updating? I suspect the single function method doesn't work since they are based on data mutation not diffing (not unlike Mikado's Helpers, the only difference being is that data isn't bound to a single template so it has to be a bit more generalized). Again Solid's reconcile method could probably work here, but it is less optimal (obviously since it is less direct). This poses a bit of a problem since it means that in none of the tests really show these libraries in their natural environment. However, I understand why they are incompatible it just too bad.

[ryansolid]

On an aside, I realize my position might seem contradicting, but don't lump me in with the VDOM authors. I'm not opposed to the helper functions(although it's arguable how comparable they are in benchmarks when other libraries aren't using them). I just strongly believe that the only option is keyed(or referentially keyed), no pools, and external stores(using mikado vernacular). Keyed and no pools for consistency, and external for data sharing. The funny thing about external is once you start it permeates everywhere since other templates require same data etc. Reconcilers are just a result of understanding performance overhead of granularity in some cases.

If you worked under the same constraints, I'm not sure we would have come to that different conclusions.

[ts-thomas]

Thanks a lot Ryan. I have to admit, I have not recovered from the Reddit slaughter yet. For some reason that was very very important to me. I really like critics, because just that makes things better. But when I feel that every attempt to solve that just hits the wall, the critics starts to become just a pain.

[ryansolid]

Ok, I understand your benchmark. I think the keyed/non-keyed are legit. I did need to change one thing to get it to work with Solid. The update function mutates the data which in turn mutates the data internally stored in Solid, so when diffing happens it thinks there is no change. Cloning the items before the update resolves it. Ie.. changing ln163 of bench.js to clone = enforce(update(enforce(items), index));

I think the data-driven benchmark is just broken fundamentally. It just doesn't make sense. The VDOM libraries will still just use their keys so they don't care about what this is testing. The reactive libraries need to manage their own data changes so they are bypassed too. While the DOM reconciler needs referential consistency in these libraries the data setter may or may not depending how it does data equality checks, if it does. The library will either see no change (like Solid State) and not update, or it will always see the change (like Surplus or Solid Signals) so regardless of keeping references, the test doesn't work. Shallow cloning the array will trigger the update in all cases but it will never be fine grain since again no diffing.

Even with data reconciling(diffing) the data-driven benchmark mutating the data causes any library that internal maintains its data to not work since the data it is holding from the same reference has mutated as well. So every comparison will register as no change. Why store a reference? Since these library's internals depend on mutation, ie static references, cloning means that it is broken right from the start. The only way to make these libraries work is for them to perform the data mutation.

[ts-thomas]

Thanks. the data-driven impl is just a draft. The reason why I want to add those category is that data-driven libs can show its strange, because I have them on my list for keyed and non-keyed and they cannot show the benefits there.

[ryansolid]

I made a PR: https://github.com/nextapps-de/mikado/pull/22.

I will close this issue and any discussion can carry on there.