Opportunities for improvement

[HendrikThePendric]

This issue is meant to be a place where we can collect ideas for general improvement. Things that work but could be done better. In the future we can create JIRA tickets and perhaps define a sprint based on things that are reported here. Just post comments with ideas below..

[HendrikThePendric]

Endpoint Errors

We have a helper called parseEngineError which we use to parse request errors, it returns an EngineError type. However, when calling an endpoint via dispatch the type information is lost:

• Calling await dispatch() will result in having an error object of type EngineError | SerializedError
• Calling await dispatch.unwrap() will result in the error being thrown, and the error type in the catch will be any (or perhaps it's unknown)

This is quite inconvenient since it prevents us from reading known error fields. Some further investigation is needed into how to deal with this in the least inconvenient way. Some ideas:

• The most obvious thing is to have a type-guard in place
• Perhaps another helper asEngineError can be added to that return an EngineError. It could internally call the type-guard and return the input as-is when receiving an EngineError and otherwise return parseEngineError(error)

[HendrikThePendric]

ID vs UID in metadata

The metadata store deals with many different types of metadata (and corresponding type-guards), and we have a variety of metadata types, both for the items as they are added to the store (inputs), as well as for the items that have been normalised and present in the store.

Having these type-guards for the store-items is very useful and working well. But when adding items to the metadata store, the type-guards are making things very cumbersome. The root cause of this is that theme metadata we're dealing with is different than I initially expected. I anticipated metadata to mostly be coming from the metaData response data field, with a few exceptions. But in reality there is way more metadata being extracted from other fields than I anticipated.

We need to somehow make the normalizeMetadataInputItem more flexible on the one hand, so that adding slightly unexpected metadata won't cause errors and additional work to deal with it, yet on the other hand, strict enough so that we do not end up with "bad metadata in the store".

And on a very practical level, we need to remove the idsToUids helper. This is currently being used to transform "extracted metadata", which mostly has an id field to look like regular metadata, with a uid field, so that the normalization function doesn't throw.

Another practical issue that rears it's head every once in a while is that when we normalize the metadata, we do not have access to the current object key, but only the value. But sometimes we deal with metadata that needs to use the key to populate the id field. It would be beneficial if the normalization function receives the key as well, when available. The metadata store can also accept arrays and in this case there obviously is not a meaningful key to be found.

[HendrikThePendric]

Transforming the visualization response

In various places we do not work with the visualization object as we have received it from the web api, but a slightly modified version via transformVisualization(). Currently we are storing the "raw" version in the redux store and we call transformVisualization() where needed, which is already in at least three place. We should probably keep storing the SavedVisualization as the raw response object, but perhaps the CurrentVisualization should actually be the transformed version.

This could possibly mean quite a few changes to the type definitions etc, but will probably be beneficial in the long run.