Using Ember I have a parent route with two nested child routes each child with a dynamic segment. The parent route does a calculation on its model to determine the “default” value of the dynamic segment for its child. Then the first child does the same for its own child route.
Everything is working well. However, what I’m seeing is that the adapters for the parent route and first (outer) child are being called twice. This causes a performance hit.
At each point where I do the calculation for the dynamic segment, I then do a “transitionTo” with the calculated value to load the child route. This is happening in the afterModel hook. I’m guessing that’s where the problem lives.
I’m able to prevent the second call to the adapter by checking the store to see if it’s already cached by that id. Is this what I should do or is this a hack required only because I’m misusing transitionTo in afterModel?
Related
i have a grandparent component that a service for Observable response of HTTP get request.
i need those results to be passed to 2 child components , load to a table (if there's results) and only then the child component should be render.
how can i achive that? i guess a service will be the right way to go but i need the results to be available before the child components view rendering, so maybe there's a component lifecycle hook involved it the solution as well.
i tried transfering the data using dependency injection on the grandparent but the child was already rendered with no data.
i also tried a bit with services but was unable to achive the result i want.
i'm using Angular 5.
Probably you can conditionally (with *ngIf) show/hide your child components. For condition statement you can check whether or not your Result object is initialized.
i used EventEmitter on the service and subscribe to it by the child component.
that solved it and handle the dynamic data loading for me.
I am new to Angular and am trying to understand the order it processes a files applications.
So, from my understanding of the order:
1- main.ts is processed and, and the bootstrap method belonging to the platform that is imported accepts the root module file as an argument.
2- app.module.ts is processed which will import all of the necessary packages and application files required for the application. Here is also where all of the different components and directives and what not of the application are declared for use in the application, and where the applications root component is bootstrapped leading to the component tree model being rendered from the top down.
3 - This is where I am struggling to fully understand whats happening.
So beginning with the root component being rendered, Angular will follow the parent child path down the tree of the root components child components and render them in order?
So, say after the AppComponent declaration comes the BookItemComponent followed by the BookItemList component and lastly a directive called FavoriteDirective.
So AppComponent is started and renders the parent custom DOM element in the body of the applications markup.
Then, nested within this comes the BookItemComponent which creates another custom DOM element called . In this components class we have an input selector called bookItem.
Then, nested within this comes the BookItemList component, which contains an array of book items called bookItems.
Finally, the FavoriteDirective which just handles some simple host binding to create a class for the host element.
So my question in a nutshell -
Say the BookItemComponent is rendered but it has some bindings within its markup that is dependent on code from the BookItemListComponents class or the FavoriteDirectives class.
Would Angular skip ahead of BookItem and look at those files? Or would Angular pause its processing of the BookItemComponent class, skip ahead and look for a data match for the item it cant interpret yet? Or maybe stop and iterate to the next component and move forward in order and once it finds the data it needed for the items it couldn't interpret yet then return to fill in the gaps?
I am finding it hard to follow the path of rendering when I see this happen. Maybe I am just thinking about it incorrectly?
Not sure what you mean with "find the data". Binding are explicit where to look for data. If a field a binding refers to doesn't have data yet, then it either throws if this makes the expression invalid like {{person.name}} when person is null (you can work around using {{person?.name}} to avoid an exception). Otherwise Angular will "find" the data after it becomes available and change detection is run.
i'm very confuse about how ember controller works.
I'm starting with ember and ember-cli now, and i would like to understand more about how controller works.
If i have an nested route called new, inside a events resource, i should i have:
models/event
routes/events/new
templates/events/new
What about controllers?? I just work one simple controller, or should i use controllers/events/new too?
There isn't any generator command that will create every resource for me? I need call one by one?
Thanks.
What about controllers?? I just work one simple controller, or should i use controllers/events/new too?
This mainly depends on what is your controller needs to do. If it's only the essential stuff the controller does anyways, Ember will create that controller under the hood for you and automatically bubble actions up to its parent controller.
No better place than Ember guides to read what a controller is used for:
The simplest definition is:
Controllers allow you to decorate your models with display logic.
This means that you basically use them as the main communication layer between your route and your template. Essentially, you model comes from your route, through your controller and into your template. Actions happening in the template go up to the controller and then to the route. Therefore, controller is essentially the middle layer where you user your model (and other data) to control what is shown to the user, control what a user can do, control where can they navigate etc.
However, be aware of the plan for the future:
Controllers are very much like components, so much so that in future versions of Ember, controllers will be replaced entirely with components. At the moment, components cannot be routed to, but when this changes, it will be recommended to replace all controllers with components.
This means, that right now, controller responsibility is limited to two things:
Maintaining application state based on the current route
Handling or bubbling user actions that pass through the controller layer when moving from a component to a route.
All actions triggered on a template are first looked up on the controller, if it is not handled or bubbled (by return true) in the controller, they are looked up on the route.
Therefore, controllers for your /events or events/new routes aren't necessary at all, only if you want to handle things happening on those routes right away (in a smaller scope) instead of allowing everything to bubble up to the ApplicationController.
There isn't any generator command that will create every resource for me? I need call one by one?
Yes. Since, if you don't specifically create a controller, Ember just generates one for you behind the scenes. You need to specify where you want to handle things yourself.
You should visit the link I gave above (or here it is again) to the Ember guides that have many more examples in much more detail.
I'm looking into mobservable but I'm having some trouble coming up with a good model to do url routing.
Because of how mobservable works with React using a standard react-router does nothing when you change the url. Only if we crudely pass the url path down into the Handler stack to make them reactive do I see some changes.
I feel this needs a different approach. Of course I could hack some custom thing but I kinda like react-routers way of nesting the urls and the solid Location/Link features.
I'm working a (non public) project that uses both mobservable and react-router. That setup is basically as follows:
Create all your routes, but give them all the same handler, your root component.
Introduce reactive state that stores your ui state (like, currently open document for example)
in the router.run callback, use the data that is passed in (the second argument) to update your ui state and to kick off the necessary data retrieval and such. In the end of the callback, just render your handler. Depending on your further setup of the root component you want to pass it the ui state or nothing at all.
For us that setup worked fine so far, so please let me know if you run into any trouble.
EDIT
Another setup using Director can be found in the Mobservable TodoMVC example
Linking this because I found it helpful. I am basically following the approach out here: https://github.com/contacts-mvc/mobx-react-typescript/blob/master/src/components/ContactDetails/index.tsx.
Initialize the store/model in the app's index page or wherever the routes are defined. Then pass the initialized store to the component. Inside the component componentWillMount grab the ID off the route and pass it to a function to load your data.
If you already had data loaded then make a method that changes the selected item. Make sure that select item property is observed and it should automatically update the UI. I think that is what #mweststrate means by UI state.
When should I be using router actions as opposed to using controller actions? I know they both serve different purposes but not sure why.
Thanks.
No, technically they serve the same purpose, it's more a matter of where you want actions to be handled/scoped.
Actions are bubbled in a very specific fashion. From the dom they hit the associated controller, then that controller's associated route, then up the route tree (defined by the router mapping). http://emberjs.com/guides/templates/actions/#toc_action-bubbling
So if you think the action will never need to be used past the controller (aka you won't ever want to use it from some child route) then the controller is appropriate, if you think maybe a child route will want to trigger the parent's action then inside the route it goes.