I wrote a blog post exploring the concept of the Runtime - the thing that turns pure code into a real application.
It also contains a lot of ideas on architectural patterns for Elm applications. Enjoy and let me know what you think.
Excellent article!
One question I’ve had when thinking about effect and effect-esque approaches when it comes to stateful components is how do you prevent something akin to a memory leak?
That is imagine you have a bunch of stateful components (from scratch, so you’re not allowed to use built-in effectful HTML nodes), perhaps textboxes that can be focused and allow users to type in text. Let’s say that the frontend can dynamically create and destroy an arbitrary amount of them. So the user generates 1000 of them and then deletes 999 of them.
Is there a feasible effect pattern that lets your custom runtime delete the bookkeeping state for those 999 textboxes when the user deletes them instead of just keeping them around in memory?
Because as far as I can tell the main ergonomic way of doing this in Elm is to, when writing code, assign hard-coded, unique IDs to each textbox (mildly annoying but easy enough), that are then stored in some state maintained by your custom runtime, but because of the unidirectional flow of data, there’s no way of implementing a “garbage collector” to clean up unused ones.
As I write this out though, I wonder if this can just be fixed by combining a custom view type with the state, and keeping the view in memory so that it can be periodically inspected to wipe out any unused state that doesn’t have a corresponding view.
If that works I think that’s actually really promising for animations!
1 Like
If you look at the stateful views Ellie, you can see that there is already a decent amount of bookkeeping to manage that. Essentially the code maintains a parallel rose tree keeping the view state. However, for doing this at production quality you would need to make sure you do proper reconciliation and for doing that performantly you will indeed need keys (hence we have Html.Keyed, except here you would need to implement that yourself).
I think more investigation into this would certainly be helpful. I would personally worry about performance, although there are some interesting possibilities (like having control over being able to skip rendering entirely).
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.