feat: ColorMapFunction type in WellLogView

[iWowik]

• Add possibility to use color function (ColorFunction type) in all cases when color table (ColorTable type) could be used. (Closes [NGRM] - In SLV, provide the option to color log by color function #2054)
• Add PropTypes for main react components.
• Fixes: WellLogViewer, Typescript - Wrong type definitions #2259

BREAKING CHANGE:

• colorMapFunctions array replaces colorTables array to combine color tables and functions in single array
• colorMapFunctionName and reverseColorMapFunctionName references replace colorTable and reverseColorTable references (JSON files also should be changed)

[w1nklr]

Does it make sense to specify both color function array AND color table array ?
What is the behavior if both are provided (the API allows it) ?
Can the design use one single property to handle both functions and table ?

[iWowik]

Does it make sense to specify both color function array AND color table array ?
What is the behavior if both are provided (the API allows it) ?
Can the design use one single property to handle both functions and table ?

@w1nklr Color table array could be easily read/written from/to a JSON file.
Color function array could not be written.
So it is convenient to have two different array of homogeneous elements.

If both color table and color function are referenced in a template then color table is used.

If we want to have the only reference for both color sources then we should mix color tables and color functions in a one array of inhomogeneous elements.
In this case we would use the old names for references in a template (colorTable, inverseColorTable)
But such names become a little misleading. Should they be renamed in something like colorTableOrFunction, inverseColorTableOrFunction?

[w1nklr]

Does it make sense to specify both color function array AND color table array ?
What is the behavior if both are provided (the API allows it) ?
Can the design use one single property to handle both functions and table ?

@w1nklr Color table array could be easily read/written from/to a JSON file. Color function array could not be written. So it is convenient to have two different array of homogeneous elements.

If both color table and color function are referenced in a template then color table is used.

If we want to have the only reference for both color sources then we should mix color tables and color functions in a one array of inhomogeneous elements. In this case we would use the old names for references in a template (colorTable, inverseColorTable) But such names become a little misleading. Should they be renamed in something like colorTableOrFunction, inverseColorTableOrFunction?

OK. I won't fight to get one single prop to handle both the tables and the function (even if I think it's not a good API).
But if you want to keep 2 props; please make sure to have a super clear doc. The doc should not leave any doubt about the behavior if both props are defined.

[iWowik]

OK. I won't fight to get one single prop to handle both the tables and the function (even if I think it's not a good API). But if you want to keep 2 props; please make sure to have a super clear doc. The doc should not leave any doubt about the behavior if both props are defined.

@w1nklr, I like your idea to combine color tables and color functions. Because it simplify code.
But the only question is how to name array and references to its elements:

• Leave them as they are: colorTables for array and colorTable, inverseColorTable for references, or
• Change them to reflect the possibility of using not only the table, but also the function

[w1nklr]

OK. I won't fight to get one single prop to handle both the tables and the function (even if I think it's not a good API). But if you want to keep 2 props; please make sure to have a super clear doc. The doc should not leave any doubt about the behavior if both props are defined.

@w1nklr, I like your idea to combine color tables and color functions. Because it simplify code. But the only question is how to name array and references to it elements:

* Leave them as they are: colorTables for array and  colorTable, inverseColorTable for references, or

* Change them to reflect the possibility of using not only the table, but also the function

Let's use colorFunc, that can be a color function or a color table.
It's not the best name, but colorFunc is already used for maps, either as a color function or a plain color value.
I'll probably extend it to include the colorTable to have an unified naming for our API.

[hkfb]

Since this is a breaking API change, suggest using the "feat!" prefix in the title and a "BREAKING CHANGE: [describe what is breaking]" in the description.

[hkfb]

Looks like there is a prettier formatting issue in the python wrapper code.

[hkfb]

🎉 This issue has been resolved in version wsc-common@1.0.0 🎉

The release is available on GitHub release

[hkfb]

🎉 This issue has been resolved in version subsurface-viewer@1.0.0 🎉

The release is available on GitHub release

[hkfb]

🎉 This issue has been resolved in version well-log-viewer@2.0.0 🎉

The release is available on GitHub release