Closed Hofer-Julian closed 4 years ago
Are you saying there's no slowdown to using virtual dom like vgtk
does?
I find the slowdown documented in the readme more predictable in terms of performance in relm than with using a virtual dom.
Are you saying there's no slowdown to using virtual dom like
vgtk
does?
I honestly don't know.
I find the slowdown documented in the readme more predictable in relm than with using a virtual dom.
I feel the same way, I just wonder if this feature brings more surprises and complexities than it brings benefits. What do you say about that? :)
You're totaly right about the complexity. Unfortunately, removing it from relm would require a complete rewrite as I would use a totally different approach now. But, such a task would be a big undertaking, which would take a lot of time, which I don't have for this project right now.
Interesting, I didn't expect that it would have large consequences, as I always considered it an non-essential feature.
Well, it's only one part of relm's complexity.
I'm closing as I'm happy with the current behavior.
I think that currentlz this feature is not very useful, as it might introduce unwanted behaviour (as the potential slowdown discussed in the README) and it doesn't work when the attribute is modified though anything else then an assignment (and even there are exceptions https://github.com/antoyo/relm/issues/44).
Certain problems can of course be attacked, vgtk solves some of the problems by updating the view after the equivalent of rem's update function is executed.
I feel that it might not be worth to support all of this features's edge cases (if its even possible), but maybe I just overlook all of the benefits it provides :)