data format types which are independent of the view

[Shiti]

Types/Interfaces with common fields and a well-defined mechanism for handling the update data structure will make it easier to develop and validate custom components. These can then be used to define basic implementations of components as well as simplify extending them.

Currently, most components define their props and expose it as types but this is not uniform.

• In case of the text related types, there is a TextProps and UpdateableText which are used in both text and markdown components.
• In some of the types, some fields got added based on the implementation instead of the data, such as OpenLayersMapProps, RechartsTimeSeriesProps, YoutubeVideoProps. The issue with this is that it makes it harder to maintain functional parity across different implementations of same component. For example, a timeseries component using d3.js or chart.js were to be implemented.

[Shiti]

I've started a draft PR #29 with an approach to handle this

[lyjeileen]

Hi Shiti! So you are suggesting that we should have a general type for a category of components, right? We might have to add different props or have different types for the same props when implementing different libraries. If we need to do this, is it ok to have a library-specific type extending the general type? For example, tooltipFormatter props has different types in Recharts and Chartjs

//Chart js
 tooltipFormatter?: (
    context: TooltipItem<'line' | 'bar'>
  ) => string | void | string[]

//Recharts
 tooltipFormatter?: (value: number, name: string) => [string, string]

[Shiti]

@lyjeileen by props, I'm assuming you mean fields or properties.

I think the interface/types for data-format should be independent of the implementation. The implemented component can provide any additional custom functionality as desired. Also, components do not need to provide all the possible features on initial render, these could be provided through more options or settings, etc.

[kaseyvee]

@Shiti When you say options or settings, would an example of this be something like a toggle/dropdown settings/etc. that the end-user could use rather opting in on a certain functionality through some field/property?

Ex. I see in your pr for the OpenLayersMap component you've removed the zoom field from the interface, though users can still zoom in and out.

[Shiti]

yes, you are right. In cases where a value is required, the component could use a default for the initial render and then update it based on user interactions and/or options/setting tweaks