Related Discord discussion -- ReArch/React tree fine integration

[busslina]

https://discord.com/channels/102860784329052160/103696749012467712/1232020137591308379

[GregoryConrad]

W.r.t. the comments on that discord, ReArch is a lot more powerful than zustand. You can use composition across states/app-level components and features/side effects. No other library I’m aware of lets you use composition like that to solve virtually every problem out there.

Actually just wrote a bit on that here: https://old.reddit.com/r/FlutterDev/comments/1c801tv/flutter_design_patterns_research_for_flutterdev/l0bkvi2/

feel free to link it in the discord 😝

[GregoryConrad]

The same is true for signals too—ReArch is similar to signals but with the ability to use a lot more powerful composition.

[busslina]

feel free to link it in the discord 😝

Done

[busslina]

Workiva/react-dart#394

I don't really know if useSyncExternalStore is the solution I need to accomplish the ReArch/React tree fine integration.

Also, it seems only available as hook (functional Component) and not for class Component.

[GregoryConrad]

I would help ya out more, but unfortunately I’m not too versed in the React space. I only touched it once for a total of 10 minutes…

[busslina]

No problem! Thanks for all

[busslina]

I'm just about to giving up with this React port... and maybe creating my HTML/JS framework (on top of web instead of html)

[busslina]

I don't really get it.

Up to now, I made it work, but whenever there is a rebuild (even on a leaf) the whole tree is rebuilding. I don't know why, maybe it's because I'm using the same ComponentHandle (the root component one) for all the tree.

Can you take a look on it (see example/web/main.dart)?

Can advice me based on this code?

https://github.com/busslina/busslina-dart-web-framework
Video_2024_04_23-1.webm

UPDATE: now it's not rebuilding cause I change usage from CapsuleHandle to ComponentHandle (only using the root one), but I feel that I'm closing the gap...

[GregoryConrad]

The idea is:

Component aComponent(ComponentHandle use) {
  return Component()
    .key(globalKey(123))
    .child(padding(8))
    .child(bComponent); // will add the use(bCapsule) call later on
}

Component bComponent(ComponentHandle use) {
  return Component()
    .child(container(...));
}

Would then be evaluated into something like:

BuiltComponent aCapsule(CapsuleHandle use) {
  return aComponent(ComponentHandleImpl(use)).render();
}

// executing aCapsule would then create this dynamic capsule:
BuiltComponent bCapsule(CapsuleHandle use) {
  use(aCapsule); // rebuild when parent rebuilds
  return bComponent(ComponentHandleImpl(use)).render();
}

Both aCapsule and bCapsule would be closures stored under a componentManager capsule, much like the root fibonacci capsule that orchestrates the other fibonacci capsules. They'd be stored as a combination of their type (perhaps the function itself in this case, if a functional approach like the above example is chosen), in addition to the node path to the component in question. There are also different key types, like a GlobalKey, which would have to be accounted for.

The only issue here is that this will currently cause a leak for stateful components if they are removed from the tree, but that is an easy enough API fix that I can work on eventually here.

[GregoryConrad]

You would also need to integrate some sort of context into all of this to handle scoped values (like InheritedWidget). That could probably be done with a HashMap from fast_immutable_collections (if there is a hash map in that package).

[GregoryConrad]

If I had a good chunk of spare time, I could probably just make this framework--probably wouldn't be terrible. Bit tight on time right now though.

[busslina]

Oh, I think I got it now. Anyway, I will finish my not full FP/declarative approach and once it works fine I will try to adapt to this pattern that is just much more elegant.