I have a typical master-detail page, where users are presented with a list of Customer objects, and can tap one to edit it in a modal window.
I have everything working – I pass the record to ModalController.create(), the modal opens, the user can edit the record in a reactive form, and then the modal page returns data to the calling page via ViewController.dismiss().
But I’m not happy with the pattern I’m using to return the data from the modal and update the original record. Actually, I’ve tried a couple of different techniques, and haven’t liked any of them.
I won’t post my code, because this isn’t really a question about nuts-and-bolts implementation. It’s more of a question about style and architecture. Experienced Ionic developers, assuming that the user has just clicked “Save” on a valid modal form, what do you prefer to do?
Let the modal page modify the original Customer object directly, returning nothing to onDidDismiss() callback in the calling page.
In the modal, clone the original Customer object, and return this new object to the calling page. (This is what the Angular docs on reactive forms recommend, but this weirds me out. This will break references, no?)
Have the modal page return a patch to the calling page, and let the calling page worry about applying the patch to the original Customer object. For example, the original Customer might be { id: 7, name: 'Bob', email: 'bob@example.com' } – but if the modal only allows editing of the customer’s email address, then the patch that it returns might simply be { email: 'bob2@example.com' }.
Something else?
Bonus points if you can direct me to sample code which handles this scenario well! Thanks!
I hate the third option. Far too much effort for the benefit, very tedious and error-prone.
The choice between the first and second options would depend on a few factors, most notably the likelihood of needing a change history at some point, for an audit trail or undo feature, which would be very hard to implement with door #1.
To look at it from another way, what you call “break references” can be considered a good thing, because having objects mutate out from under you is one of the more puzzling aspects of JavaScript, at least for me.
Either of the first two options seem defensible to me, but I would advise consistency. Either the page that pops the modal “owns” the Customer object, in which case you go with the second strategy, or it doesn’t, you use the first strategy, and that page must act defensively by passing the modal a clone if needed.
One other possibility comes to mind if you have a service provider that has a relatively cheap customerById() method, such as a transparent cache. In that case, the actual Customer object need not necessarily be passed to the modal at all, only the id, and the modal can get (and update) the Customer by interacting directly with the provider.
This is more or less what I do to solve your problem, and I think it’s the cleanest answer to the question in your title. The concept is: a provider owns the data. Pages submit requests for the data, and submit requests to update the data. So the pages own and control nothing. That way, if there is ever a bug, I know the bug occurred in exactly one file, or in a request to that file’s code.
You might want to take a quick glance at some basic c# behavior. its really effective in handling a model/view relationship. I wouldn’t dive in too deep, and would avoid the inheritance aspect of it, but it might provide a blueprint for what you’re looking to do.
I was only using references to in-memory objects in the first place because my app needs to work offline. However, I’m quickly discovering the limitations of this approach – it’s easy to end up with long chains of references (e.g., as the nav stack grows), and things get confusing / complicated pretty quickly.
I’m now pursuing the approach quoted by Aaron – passing records between components solely by ID – using Ionic’s Storage module for my client-side data store. I believe I’ll end up with a two-layered approach: one layer to retrieve/update local records, and a second layer to persist or refresh records to/from the server.