Application Preferences Implementation

[pklaschka]

Within the planning stages of these libraries, we had already planned to support a generic way of declaring application preferences (as part of our core structure) which could, then, be used to allow Project-Specific-Client developers to easily add app-global settings that could still get rendered into one, unified (though grouped) settings page.

Here's an example of how using these APIs might look like:

            <Preferences>
                <Group name="Bildübertragungseinsetllungen">
                    <Variable key="Kameraname 1">
                    {
                        (val, setVal) => 
                            <input value={val} onChange={setVal} />
                    }
                    </Variable>
                    <Variable key="Kameraname 2">
                    {
                        (val, setVal) => 
                            <input value={val} onChange={setVal} />
                    }
                    </Variable>
                </Group>
            </Preferences>

As with #562, the goal is to provide a unified way of having preferences (in this case, application-wide), without losing the option of complexity, which is why every variable can be "as complex" as it needs to be (just pass a complex JSONSerializable object to setVal).

Still, everything rendered by this renderer can be put into the right spot (e.g., depending on the implementation, a unified settings page).

All in all, I believe that this approach provides both ease of use as well as the right amount of versatility. For really complex endeavors, of course, PSCs can still implement their own, individual, settings pages, but the combination of #562 and this should probably cover ~ 97 % of cases 😉

Why put it into the core, though?

While an implementation for a unified settings page should be put into common, the settings structure, by itself, is abstract and independent from the framework used (as long as React is used). This means that the components belonging to the overall concept (registering these messages, making them accessible in the application, etc.), by our definition, belong into core, since they could, just as well (with different implementations of the VariableRenderers, of course) be used in, e.g., React Native.

This idea's components that probably fit into common are "just"

• A unified settings page that renders the overall layout of the settings page
• Common Variable components (e.g., TextInputVariable) which cover the most typical variable types (text, number, color, ...)

References

https://github.com/wuespace/telestion-client/blob/28a85e8359b4f127a1bd956c9a14184d36e59034/packages/telestion-client-types/src/preferences.ts

https://github.com/wuespace/telestion-client/tree/ba323b41810aafc6df263899dac7d9ac7df597c9/packages/telestion-client-core/src/components/preferences