Allow arbitrary data source options in DashboardVisulisation

[FredrikAugust]

Description

Bear with me, this might get a bit confusing. If so don't hesitate to ask here, send me a DM, or call me.

In the current drafted implementation of population parameters, i.e.

https://github.com/IT2901-SINTEF01/frontend/pull/116/files#diff-b01a6c1c95562d08ab752970c643e4069e70de83e390189d9bbd8f224a18fe21R100

There's essentially a switch statement that generates a set of controls for the data source in-place. This data is then added to a global store.

https://github.com/IT2901-SINTEF01/frontend/pull/116/files#diff-7eeb8bab2802ad9120bb9d23ca0003af1c535416e48e97f300fa83fea064da9aR11-R12

https://github.com/IT2901-SINTEF01/frontend/pull/116/files#diff-7cd1314945ef5b0ae105c7554edbd674636614af44d9ba11b8e6f01b1e906909R26-R28

Firstly, we will address the state management. It is beneficial to the complexity of the application if state is stored at the Lowest Common Ancestor (apologies if you suffer from Post-AlgDat Traumas). This is because this isolates the state and ensures only the relevant parts of the application get access to the state.

This LCA will probably be the VisualisationEditor, and thus state should be kept there.

---

The second part revolves around the creation of the components to control the inputs --- and the subsequent state modifications.

What if, we add a field to the DashboardVisualisation interface called DataSourceOptions which has the following form (using type aliases);

type GraphQLParameterName = string;
type ControlType = "municipality_editor" | "lat_lon_editor";
type ControlValue = string | number | string[]; // e.g.

type DataSourceOption = { controlType: ControlType, value: ControlValue };

type DataSourceOptions = Record<GraphQLParameterName, DataSourceOption>;

The code is meant as inspiration and should be taken with a pinch of salt.

Then we could add a section in the visualisation editor which essentially iterates through the entries in the datasourceoptions and generates the relevant components. The results from these components should be injected into the GraphQL queries as parameters, and stored in the Redux store (as they should be persisted so the variables are the same on the next load).

Subtasks

• Move state to LCA
• Implement generic control component "generator" and associated types

Related sources

• https://github.com/IT2901-SINTEF01/frontend/blob/master/src/types/DashboardVisualisation.ts#L31

[FredrikAugust]

I'll take a look at this now, @fredrikbw