Hi.
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.
Thanks.
If changes to those various bits affects the url then it should be multiple routes, if not then I recommend single route.
Ok thanks.
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.
From what I understand the components loading themselves path is not very well established in ember. By that I mean there doesn’t seem to be an official answer on how to architect that part yet. What I’ve seen so far is people returning plain javascript objects with the unresolved promises from the route model hook and handling that promise custom on the component level. It may be the case that this path will become clearer with 2.0 and routable components / greater emphasis on components.
OK, I see. Thanks for your help.