Large lists don't work well in the UI. Adding them works surprisingly fine, but loading them, editing, and enabling FF inclusion lists is no good because the methods and endpoints used don't scale.
Loading in UI is inefficient because the details page loads the full segment lists, employing heavy findOne repo methods to do it. The reason it loads the full lists is not so much to support the list tables, which barely need any information, but to load everything into the ngrx store ahead of time to facilitate the operations you can take on those lists, such as to edit or enable, which for some reason were designed to require every member item 🤯 .
This doesn't scale! The functions will break.
The solution is to load only the details the details page actually needs with a lighter call. The edit function can lazy-load just the info it needs, and the enable function for FF include lists seems like it can just be a PATCH call to change this one string instead of requiring the whole object.
These will need all be fixed together, so it might be a chunky PR, but the FF, experiment, and standalone segment fixes can be independently. I'm going to start with the FF one so we can support large lists that engineering want to use soon.
Large lists don't work well in the UI. Adding them works surprisingly fine, but loading them, editing, and enabling FF inclusion lists is no good because the methods and endpoints used don't scale.
Loading in UI is inefficient because the details page loads the full segment lists, employing heavy
findOnerepo methods to do it. The reason it loads the full lists is not so much to support the list tables, which barely need any information, but to load everything into the ngrx store ahead of time to facilitate the operations you can take on those lists, such as to edit or enable, which for some reason were designed to require every member item 🤯 .This doesn't scale! The functions will break.
The solution is to load only the details the details page actually needs with a lighter call. The edit function can lazy-load just the info it needs, and the enable function for FF include lists seems like it can just be a PATCH call to change this one string instead of requiring the whole object.
These will need all be fixed together, so it might be a chunky PR, but the FF, experiment, and standalone segment fixes can be independently. I'm going to start with the FF one so we can support large lists that engineering want to use soon.