err0r500
Hi,
I recently hit a performance issue with a liveview form.
The structure the form edits has lots of association handled dynamically using cast_assoc.
Everything works fine for ~70% of the cases (with just a few assocs), but the 30 remaining percents can have more 100, 200 assocs and the users struggle a lot. In this kind of cases, websocket frames can be 30, 40 KB on each validation.
Just to give a feel of what the form does (and simplify things), let’s imagine it allows to edit staff in a movie :
movie (with a few specific fields, like title, length...)
-> has many professions (10+, must validate uniqueness in movie and not empty, with a few specific fields)
-> has many people (100+, must validate uniqueness in profression and not empty, with a few specific fields)
people are managed somewhere else, i just create a drop down so they can pick a person and add a few metadata for this peculiar profession
To stay in the example, most of my users manage indie movies with less than 40 people and everything works well, the issue are the blockbusters (and the UI should be able to handle both, so keep everything in a single page without modals or tabs or navigation because for most of my users the form is not that big. )
Do you have any advices about how to handle this ?
Best,
Matthieu
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
I’d start by evaluating if all that data needs to be handled through one huge form. I’d argue nobody wants to scrolls through a list of 200 entries editing all of them at once. They rather scroll hrough a list of 200 entries, and on some click an edit button to make some targeted small edits.
If you still want to stick to that large a form check out the RC for LV 1.1, which has optimizations for
forcomprehentions as used byinputs_for.err0r500
Thanks a lot for your response,
I agree about the UX of editing a big list. Actually, such big forms weren’t expected at first (I’d like to qualify them as “edge cases” if they weren’t happening ~15% of the time).
In fact, the users don’t edit much in these lists, they just add/remove references and i currently use cast_assoc sort_param & drop_param to achieve this. This works fine with small-sized forms but not for big ones.
90% of the websocket frame is just
_unused_<field>i’m not sure what they’re used for and if it might be a solution to just not send them.upgrading to LV1.1 seem not to improve much in my case (I guess it would if i were managing the list specifically)
LostKobrakai
That’s to me further insight to make this a static list with means of adding, sorting removing individual items with individual forms and actions handling instead of craming it all into a shared parent form.
Those are used to determine which inputs have been “touched” by a user to hide errors for not yet touched inputs.
err0r500
I agree, I already made an attempt to split the form and gave up after a few hours : i just have to figure out how not to nest them and keep the complexity not to high (because the movie example is a simplification : in my app, i have ~20 schemas involved with up to 4 levels of nesting)
alright, I’ll leave them !
PJUllrich
Without knowing your form structure, it’s difficult to give advice, but in my experience, it’s sometimes easier to not wrap every table entry in one huge form, but to make each e.g. a LiveComponent with one form per row.
This way, you only need to handle a form for one record at a time. If you only have a
Deleteaction per row, you don’t even need the form, just delete the record from the database and remove the LiveComponent from the template (e.g. with stream_delete/3)For editing, you can either have the row become a form or you could show a modal to edit the record.
To add new records, you can have a single form at the end of the table which would create a single new record.
garrison
See used_input?/1 in the docs for more about the
_unused_*keys.err0r500
I got some good results by splitting the form into several smaller ones with a dedicated changeset for each one. this led to a notable improvement about what the client sends to the server.
I then realized that on the server response there was a big select that was sent back each time (and for each element of the form) so I encapsulated it in a livecomponent that gets its options once then renders them only for edition.
for saving I merge all forms
.params(it seems to work fine) and apply that to the global changeset.the result is much more efficient (but I had to change a bit the layout and the UX to achieve that)
Thanks for your help !