GeoStyler API design

[KaiVolland]

12.01.2023, 10am GMT +1

This discussion should clarify on how we can improve the customization of the GeoStyler-UI.

Do we need better Contexts or do we even need a complete refactoring?

What was and what is the goal of the GeoStyler main package?

Status Quo:

Three different contexts

We have three different context where the CompositionContext is the most important context for this topic.

• CompositionContext --> Configure sub components of the Style and partially CardStyle.
• DefaultValueContext --> Provides default values for the UI components.
• UnsupportedPropertiesContext --> Provides information about unsupported properties. The unsupported properties of a style-parser can be used here to show warnings or hide unsupported fields completly.

Porperties that configure subcomponents

Additionally we have several properties on the toplevel components (Style and CardStyle) to steer the appearance of underlying components.

List of properties of the Style component that steer subcomponents.

  filterUiProps?: Partial<ComparisonFilterProps>;
  ruleNameProps?: Partial<NameFieldProps>;
  ruleProps?: Partial<RuleProps>;
  ruleTableProps?: Partial<RuleTableProps>;
  ruleRendererType?: 'SLD' | 'OpenLayers';
  sldRendererProps?: SLDRendererAdditonalProps;
  iconLibraries?: IconLibrary[];
  showAmountColumn?: boolean;
  showDuplicatesColumn?: boolean;
  colorRamps?: {
    [name: string]: string[];
  };
  useBrewerColorRamps?: boolean;
  colorSpaces?: (InterpolationMode)[];

[KaiVolland]

Context:

• Create a context that provides optional properties to the subcomponents
  • Make a concept which components should consume the context and which should just receive props
• Unify multiple contexts into one GeoStylerContext
  • beware of perfomance implications (rerender only if needed !)
• Move relevant properties from the top level components to the new context