I’m fairly new to ember so forgive me if this is a stupid question. I am using ember-data & I’m wondering whether it is better to return a hash of promises whose data can then be used to populate various UI components, or have multiple nested routes each with a single model that populate different screen outlets?
I’m guessing it’s down to personal choice but as ember is an opinionated framework I wondered if their was a recommended approach?
I’d be grateful of any pointers anyone could offer.
If changes to those various bits affects the url then it should be multiple routes, if not then I recommend single route.
I’ve got a state with two datepicker components and a dynamic table component (sortable, searchable etc). The table sits within a set of three tabs to filter the table which, when clicked, add a query parameter to the URL to tell the route to search the store for that type of data.
I decided that I didn’t want the asynchronous data that populated the table to delay the display of the datepickers and the state description text located above the table. So, I put the table component within a nested route (/list) in order to use a route loader to display the loading indicator. This meant that the description and datepickers appeared and a loader showed over the table component until it’s promise resolved and showed the data in the table. So, the only reason I used the nested route was for the loader.
Aside from the fact that I wanted to display a loader would you say in general that this state should use a nested route (because it does change the URL) as it seems perhaps a little overkill in this case? Perhaps there is a different way in which I can display targeted loaders (are there component loaders?)
Thanks for your time.
OK, I see. Thanks for your help.