Suggestion here:

Is there a way to avoid provider specific logic in the views? I see we have this in 3 views currently: this one, economy and fixedincome.

IIUC these are now used to "standardize" the data provided by providers to create a standardized chart. Would it be possible/make sense to move this logic to the provider level? For example to a custom model_dump in the Data model which could add this remaining additional layer of standardization that is currently missing. This would make the views more universal, without hardcoded logic for providers which might or might not be there and generally would facilitate better modularity. Let me know what you think

I like where your head is at, but I don't think this PR is the place to address this. We would need to reconsider the entire flow of the views.

For one, any presentation layer will always need a level of abstraction on top of the Data model. There aren't really many scenarios where dumping raw data into a chart is desirable.

If we were to move some logic to live in the provider, then we essentially need to create a chart/view inside every provider data model definition. This would create a lot of overhead and make assumptions for views that may not be installed or are not desired. Right now the charts are fully decoupled, but mixing it in the provider logic would blur that.

A custom "model_dump" doesn't necessarily help because the data needs to be aggregated as a complete table before some of downstream decisions can be made. A model_dump would only operate on single rows.

Additionally, there is logic applied that handles the user passing in data that is not directly from the raw data model output.

At the provider level, we don't have access to the OBBject and the ability to modify locals to pass forward to the charting extension.

That being said, the Platform charting ecosystem and framework needs to be revisited anyways - i.e, get rid of frontend-components - so, your points are very valid and should be a consideration when planning a modernized backend.

Thanks for this thought out reply. Reading it was joy to my eyes and brain. ❤️