err0r500
How to handle forms with lots of assoc
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
Marked As Solved
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 !
Also Liked
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 for comprehentions as used by inputs_for.
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.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









