I had some state groups (I organize states in 1px by 1px group elements and name them #loading #data #ui. This helps me organize my states) and plugin groups (same idea as the state group) stored in popups. At a certain point in time they didn’t load on page load and I realized it’s because of the popup. I just store them in a floating group at 1px by 1px so I know they load.
IMO the best way to control loading of data is still using states. Why?
- You can only alter states through actions in a WF
- State lists do not update in realtime because you cannot store Search expressions so I know I will only load data when I want it to load. Realtime search per item in a state list still update in realtime
Because of the above:
- I have more predictable control.
- I can batch load data by scheduling custom events (eg. load 50 first then load the rest at as part of the UX or when I know there isn’t much load happening on the page).
- I can load data in parallel using scheduled custom events too (eg. one WF running 2 schedule custom event actions 1sec apart)
- I can pass a Search as a custom event parameter or/and result (eg. The custom event can trigger a “No Search Results Found” WF or otherwise based on the search count.)
- I now don’t have to deal with messy conditionals in RGs or whatever. Only RGs and plugins can store realtime search lists. For me I have my own plugin to store those (I needed triggers when a realtime list gets updated)
For your use case you can have different custom events loading different data. Then run (when appropriate) a WF that runs whichever custom event based on the user type in action conditions.
1 Like