UI making additional calls to back-end when viewing element list
Opened this issue · 5 comments
When viewing the list of data elements in a data class, the UI is also making calls to get the details of any models used as model reference data types. So one call to list data elements might be followed by a page-worth - 20+ - calls to the back-end. It's not clear whether there is information that the secondary calls need that is not returned in the first, so worth checking this isn't a work-around for the back-end not providing all the data.
In element-data-type.component.ts, there's a call to loadModelResource() on line 90 and it's this function which is making the call. Commenting it out doesn't appear to make a difference, but someone who understands the code should check!
I am unable to reproduce the issue. Viewing data elements in a data class with the default content did not produce multiple request log entries in the browser's network tab.
EDIT: Apologies. Missed "model reference data type" part. The default content does not seem to have model reference data type.
The reason for the additional calls is because not all the information is being returned by the backend. Take this example here:
The data type here is a ModelDataType and provides almost all details except for the label for the Reference Data Model itself. To display that, a separate call must be made to GET api/referenceDataModels/{modelResourceId}. This is repeated for any other data elements which use a ModelDataType.
There are some ways to fix this:
- Don't make the individual call to fetch each model, so the Data Elements table will only display the Data Type label and type, but not reference the actual model it is linked to.
- Return the label of the model resource in every data type e.g.
dataElements[0].dataType.modelResourceLabel, which would require a backend change. - An alternative backend change could also be to provide an API endpoint that accepts a list of IDs and returns all catalogue items in one response to reduce the network traffic.
What are your thoughts for resolving this @jamesrwelch?
In most cases the name of the data type is irrelevant - to the extent that I was thinking of hiding it in the UI in most cases. The name of the model resource is far more important - and I can't think of many - or indeed any - reasons why you'd be ok with receiving the id of the model resource but not its name. You might argue that it would be helpful to have model version, etc too, but let's leave that for now.
Anyway, in summary, let's change the back-end to return the label and update the UI not to make extra calls.
I've created a new mdm-core issue (listed above) to fix the backend and return what is required. This issue cannot start until that change is completed.