I was wondering if there’s a best practice for handling multiple different models per route while using pagination. For instance:
Let’s assume I have a car model and an image model. Each car has many images. But there’s also a house model that has many images. Visiting /houses/1 or /cars/1 would usually get the model with the according ID from the backend (assuming ember-data here, but anyway).
Now that I need the images as well I could load them in afterModel or setupController, depending on the point in time I need them. So far so good. Now house/car are somewhat the “main” model since they are loaded into model/content, while the images are “on top”. But if I want to add a lazy loading like Instagram has, I’d have to paginate through the images. Again, possible, but kinda problematic to implement in a general way, plus it breaks most pagination addons.
Discourse if currently loading both the topic and it’s posts in the model hook, saving the data directly on the topic instead of on the controller or route.
Long story short: Would it be good/preferable to make the images the “main” model and load the house/car as the “on top” model or the other way around or discourse’s version or something totally different.
This is especially interesting for API’s that don’t support ember-data’s way of loading hasMany relationships.
I’m also interested in how you guys handle pagination with filtered arrays, e.g. this.store.find('image', { car: car, offset: offset }) in a nice and general way. Currently I get the query object from the array and merge it with my offset/page parameters to update the array using a backend call.
Curios about your opinions!
Btw, related: Best practice to get multiple data from route before the view rendering? - #4 by denisnazarov