AbstractDetail should use Resolver data as is

[Adrien Crivelli]

In NaturalAbstractDetail.ngOnInit I think we should simplify like so:

- this.data = merge({model: this.service.getConsolidatedForClient()}, data[this.key]);
- this.data = merge(this.data, omit(data, [this.key]));
+ this.data = data;

If my understanding is correct we try force default values on whatever is coming from the route. But the route is already populated with default value via NaturalAbstractModelService.resolve who called getConsolidatedForClient earlier. So our current code seems to be entirely redundant as long as we properly use revolvers.

So we should double-check that resolvers are used correctly in all our projects and simplify this code.

[Samuel Baptista]

Not exactly. While answering you, I found out there are some incoherences in resolving and defaulting data. Probably the result of many iterations.

There are two differences to take in consideration :

Default values more consistently

We should change AbstractModelService.resolve() to include getConsolidatedForClient's result when we provide an ID too. If we don't, we would loose some completion of the result. We actually do it in ngOnInit in all cases (new item or existing item).

   if (id) {
-     observable = this.getOne(id);
+     observable = merge(this.getConsolidatedForClient(), this.getOne(id)};

ngOnInit would be simplified :

- this.data = merge({model: this.service.getConsolidatedForClient()}, data[this.key]);
+ this.data = merge({model: data[this.key]);

This would have another impact : apply default values returned by the server on all resolved items. Actually, only the main one is defaulted in controller side.

Before (actually consolidated is unconsistant) :

{main: {model: consolidatedFetched } } 
{other: {model: fetchedOther } } 

After (all resolved models are consolidated) :

{main: {model: consolidatedFetched } } 
{other: {model: consolidatedFetchedOther } } 

Important : that means Resolvers must always be provided, there is no fallback. An error could be sent if nothing has been provided in data[this.key]... ?

Template access

When we resolve something, we declare it in routing this way (we can have multiple resolvers) :

{ 
resolve : { 
    action: ActionResolver,
    other: OtherResolver
    } 
}

In controller, router.data is :

{action: {model: fetchedAction, statuses : [...], priorities : [...]} }
{other: {model: fetchedOther } } 

In AbstractDetail.ngOnInit it targets data[this.key] where this.key is human setup and specific to a controller. This transform the router.data value into the controller this.data into :

 // action item is consolidated and "action" key becomes "model"
{model: consolidatedFetchedAction, statuses : [...], priorities : [...]}
{other: {model: fetchedOther } } 

At this final stage, templates access data.model.name.

If we replace ngOnInit as you suggest, we would have :

{action: {model: consolidatedFetchedAction, statuses : [...], priorities : [...]} }
{other: {model: fetchedOther } } 

And all templates should be updated to access data.action.model.name.

[Samuel Baptista]

We can easily consolidate with first step : moving getConsolidatedForClient in resolve() and clear it from AbstractDetail.ngOnInit.

And if you are motivated to update all templates, you can process the second step : change AbstractDetail.ngOnInit as you suggest.

[Samuel Baptista]

If we change something that impacts the template, we must adapt PanelService to expose the same object structure of resolved items to the template. Same components are used in Panel routing and Angular routing.

[Adrien Crivelli]

include getConsolidatedForClient's result when we provide an ID too

yes... but I am not sure in what case we need to add default values to something that already is persisted in DB, so assumed to be valid.

Resolvers must always be provided, there is no fallback. An error could be sent if nothing has been provided

yes

I didn't think of the impact on templates though... I also didn't realize that our current situation feels a little bit inconsistent between model and other.model:

 // action item is consolidated and "action" key becomes "model"
{model: consolidatedFetchedAction, statuses : [...], priorities : [...]}
{other: {model: fetchedOther } } 

But actually I didn't find any cases of other.model in non-panel routes templates, via the following command. So I guess we don't need to worry too much about that incoherence and focus only on default values handling, keeping the structure the same as now.

grep '--include=*.html' -hPor  'data\.\w+\.model' client/app/  | sort -u

I suggest we create a PR and review it before merging.