Awesome

[ghost]

Am loving this approach. The fractal self similar aspect is create.

One concern I have is about performance. When a data change occurs is it updating all of the widgets , even though only one widget is affected by the data change ? I am not sure.

[p69]

Hi @gedw99 , Yes, in general dispatch function triggers update from the root (DarteaWidget). This is fine in many cases, since rebuilding widget doesn't necessary enforce redrawing (because widgets tree it's like virtual-dom tree in web). Sometimes this could be an issue. For example when you have list of cards with complex layout and you want to update just some text inside one item. In such case there might be junks while scrolling and updating occurs at the same time. If it is real problem so one way how to solve it - is using nested DarteaWidget (via program.build() or ProgramWidget). It helps us to decouple child from parent in model and update levels, and just keep relation in view (create children in parent's view). And if event was triggered only for one specific child, then it doesn't trigger parent's updating and redrawing.

[p69]

What I have described above is related for situations when update occurs in child and propagates to parent. Also I'm thinking about some kind of conditional widgets builder. In case update occurs in parent and we want to stop updating somewhere in widgets tree. Something like this.

Widget view(BuildContext ctx, Dispatch<Msg> dispatch, Model model) {
   return DarteaConditionalWidget(
      model: model,
      condition: (m)=>m.isUpdated == true,
      builder: (ctx, m) => Text('${m.name}'),
   );
}

DarteaConditionalWidget would store latest result of builder and if condition doesn't satisfied it would just return it, instead of building new widgets configuration. Or maybe better to use memoization trick, without condition. I'm going to try it and hopefully add it to the lib soon.

[stt106]

This is a great idea and I like it a lot. In fact I was hoping there would be such a package one day for flutter, mostly because I came to flutter from a F# background hence functional approach is really appealing to me. Though I have to say I agree with the initial question about potential performance issue. I don't know flutter deep enough to fully comment on whether it's going to be a serious issue. I think it might be useful to get one of the guys from flutter team to have a look at this approach. I am going to flutter live next week so maybe I can ask them. My gut feeling is that the functional approach, if done properly, shall work well with flutter since flutter does promote functional style to some extent. And there are built-in widgets such as StreamBuilder and FutureBuilder that support only partial update rather than full update of the entire widget tree. They're designed to work with reactive programming but maybe they can also somehow be used to mitigate performance for a functional architecture.

Anyway, I will start playing with the package, great job for creating this!

[p69]

Hi @stt106 , I'm also got into FP-trap through F#, and now can't force myself to do classic OOP. Performance is definitely essential for mobile app. I've compared FPS in this app dartea's approach with vanilla implementation. And I didn't notice any differences. Both variants were running well. I also checked if unnecessary redrawing happened when we want to update some widget in the bottom of the tree. Looks like Flutter does just incremental updates. Still, I want to go deeper into engine code just to have clear understanding how bad\good dartea's approach in terms of performance. Right now I can see that the main drawback is creating many objects (widgets, messages, models) after every state change, just like in Rx-based architectures. All the options that I wrote in my previous comment can mitigate it. I'd say that one can create good application in terms of performance using Flutter and dartea. BTW, it would nice if you can ask about it someone from Flutter team :)