I am using ion-nav to go through several pages which accumulate data entry that I want to take action on at the end. I am wondering if there is an intended way to pass data around the ion-nav component? I would prefer not to pass each page’s data on to the next page and have to accumulate a bigger data structure in each subsequent component that is not relevant to the page. Ideally, the parent component housing the ion-nav component could hold the data (state). However, the dynamic rendering mechanism underlying the ion-nav component seems to prevent EventEmitter from reaching the parent component. Normally in Angular, I would use an @Output directive to emit data up to the parent. I can’t seem to do this so is there an intended way to communicate from child → parent when using the ion-nav component?
This would come down to different methodologies among the big three frameworks, and is independent of Ionic. In my case I use Angular, so I can speak to that. On the one hand, I’ve previously just imported the parent component into the children and set values as needed. This isn’t preferred, but on a small scale it worked well. Later on I ditched that in favor of a shared service.
In my case I have a storage-manager service that loads all persistent data on init into a large object, and all components in the app can access this service to read the object. If they need to update the data, it’ll run through a function in the service which ensures the persistent data also gets the update. If you have sibling pages that all share data, this seems like a better method than using Outputs. Where applicable Observables could serve you well too.
Anyway, those are the two options I’ve had success with, the shared service being working better for me. Seems like that would serve you well.
@pslyman I agree that using a service to handle state management and data access between nav components is probably the best option, particularly if the different nav components need to share data. One could also use Subjects as a work-around to EventEmitters.
In my case they don’t really need to share data; each has isolated inputs that I could just feed back to that overarching parent component to take action on. This is why Output/EventEmitter makes sense to me which is a core Angular functionality. That’s straight up not going to work in dynamic loaded components without some logic that probably is never going to happen, so another option if that route is preferred is just to pass RxJS Subjects into the child nav components. This works well but you still end up having to pass around component parameters in a non-idyllic way because the previous nav component is responsible for passing the parameters to the next nav component.
So yeah, I think using a service allows each component to isolate logic the best, but passing forward an object of available subjects allows that outward communication pretty well and provides actionable subscriptions for the parent component. I’m a little hesitant to accept your answer as solution because I think this is also a valid solution others might want to see. I would not import the parent into the child for access to its data.
Ultimately I decided to implement a service with stateful data that each component can read and write to, which itself provides subjects that the parent component can subscribe to in order to react to states or actions. It’s important in my case to not provide the service in root (default) and to provide it specifically within the parent component, so the state doesn’t persist past the destruction of that parent component (and persist into each invocation of this nav).
Thanks, your suggestion was instrumental to deciding on this approach.