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
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 for comprehentions as used by inputs_for.
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)
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.
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 !
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 Delete action 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.
See used_input?/1 in the docs for more about the _unused_* keys.
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 !
