I think it’s conceptual. Current toString(cids) implementation is probably already good for this concept. We are good generally for majority of use cases (i think).
50kudos
chrismccord
Creator of Phoenix
citation needed. If I remember correctly, we had a convo on slack where you were rendering thousands of components per page for a visualized JSON tree? Server bookkeeping for us is very minimal, so I want to make it clear for other folks that we don’t “eat memory” for components. I forget our exact convo, but your usecase was highly specialized, and I provided the exact number of bytes that is our overhead, but a few bytes * 10,000 per page is obviously going to accumulate. It’s not fair to say we eat memory, but it is fair to say a highly specific usecase may not necessarily be served well by LiveView or something we’ve optimized for on the client.
2
50kudos
From Phoenix.LiveComponent — Phoenix LiveView v1.2.5
However, be aware that in order to provide change tracking and to send diffs over the wire, all of the components assigns are kept in memory - exactly as it is done in LiveViews themselves.
Therefore it is your responsibility to keep only the assigns necessary in each component
But I’m sorry, my components had already changed and it’s very hard to make a demo. I wrote an anti-pattern components anyway as docs say:
You should also avoid using stateful components to provide abstract DOM components. As a guideline, a good LiveComponent encapsulates application concerns and not DOM functionality
Forget me! (and forgive <3)
1