Reputation: 6289
I understand how routing and passing information between components generally works in Angular 2. For instance, you would use the following kind of setup to load a component and an accompanying specific id:
<a *ngFor="let product of products"
[routerLink]="['/product-details', product.id]">
{{ product.name }}
</a>
But let's say you're already on a route, and now you want to click a link to load a new route (with narrower information details), but all the data you're accessing is in the same product.id source as the one you just clicked away from (because they draw from the same api end-point and product.id in your api (mongoDB)). How would you go about doing that?
In this case you can't just pass in the "product.id" because you're wanting to access an array WITHIN the same product.id as the previous route/component. So you want a new route, but info from the same data source (same product.id). To clarify, the new route has "contact" for the component, and then "contact.id" for the specific parameter. But, it's not a separate data source, because "contact.id" is an array value WITHIN the product.id I just clicked away from. How would you do this?
Presently I've got a new route opening up, that lists "contact" and then the specific contact id - so the route looks like: http://localhost:4200/contact/21469568eds3913283df5cs. So that's working as expected. Just a reminder, the contact id listed here is within an array of my product.id - it's not a different data source. So how do I access information from the previous route's id in the new route? Because - again - same data source, just new route. Right now I'm getting "undefined" errors in the new component/route.
Upvotes: 0
Views: 69
Reputation: 6468
This might be a design issue. If you have a route to a product
you work with, and then open a contact
which is assigned to that particular product
(as you say contacts are an array within your product) , then you should reflect that in your route, too. For instance
/product/:productId/contact/:contactId
That way you have all relevant context information in your route. In this case a Resolver makes perfect sense for all routes that fit the pattern
/product/:productId/**
That way you'll have easy access to the product, even if you have activated a route to the details of a contact. Caching the product within the ProductResolver
might make sense if you expect multiple routes called for the same productId (and the product is expensive to get, e.g. due to complex SQL joins, or will change very infrequently)
Upvotes: 1