Best practice to store "app settings"

[Thorvarium]

Hi. I am working on a react application that has a lot of "settings" and they have a veriety of different types. Booleans, strings, arrays, etc.
What would be the optimal way to organize that on dixie to use with live queries ?

I've been debating between creating a table with a single row, but doing so kinda defeats the purpose of live queries because changing a column update the object on the react component. Yes, I could fix that encapsulating with contexts, but I am wondering if there is a better way.

Maybe creating a multirow table with column key and column valued as type "any"?

Thanks!

[dfahlander]

Good question. I'd probably suggest a multi row table with setting type as the primary key. The typing is not very good in this situation (I'm planning to improve it). So for now, you'd probably benefit from a wrapper that can take retrieve setting and return it well typed.

[Thorvarium]

Decided to go with single row X multiple columns for now to take advantage of updating multiple columns at once (dexie), types and I am memoizing the properties in a context. This way my components only change when the memoized column changed.

@dfahlander awesome job with dexie by the way. Completely changed what I am working with at the moment.

[scottrblock]

@dfahlander I would be interested if any progress has been made here, is there an issue to track this?

[dfahlander]

I think this is not a critical issue. Either go with @Thorvarium's approach or go for one row per setting. The latter would work out of the box when all values are strings, but when values are different per setting, the typing 'any' or so of the value would be too loose but that can easily be fixed using some kind of custom AppSettings class that queries dexie internally but returns cleanly typed values to its caller.

I mentioned though generically that I want to make it possible to type a polymorphic table, say "nodes" that, depending on the key given would return different types of values. This would also be an improvement in this case. There's no issue for that but feel free to create one. Can't promise that I could spend time on it in the close future but maybe someone else could do it.

[Thorvarium]

If you need a pseudocode for inspiration, that is how I've done it:

export const SettingsContext = createContext<ISettingsContext | null>(null);

const getSettingOrDefault = <T,>(settings: ISettings | undefined, key: keyof ISettings): T => {
    return settings && settings[key] !== undefined && settings[key] !== null ? (settings[key] as T) : defaultSettings[key] as T;
};

const SettingsProvider = ({ children }: { children: ReactNode }) => {
    const { account } = useContext(AccountContext)!;
    const dbSettings = useLiveQuery(() => db.settings.toArray(), []);

    const isLoading = useMemo(() => !dbSettings, [dbSettings]);
    const settings = useMemo(() => dbSettings?.[0] || defaultSettings, [dbSettings]);

    const font = useMemo(() => getSettingOrDefault<Font>(settings, "font"), [settings]);
    ...
    const enableGestures = useMemo(() => getSettingOrDefault<boolean>(settings, "enableGestures"), [settings]);

    useEffect(() => {
        const check = async () => {
            const settings = (await db.settings.toArray())?.[0];

            if (!settings) {
                db.settings.add(defaultSettings).catch(console.error);
            }
        };
        check();
    }, []);

    const updateSettings = useCallback((value: Partial<ISettings>) => {
        db.settings.where("id").aboveOrEqual(0).modify(value).catch(console.error);
    }, []);


    const contextData = {
        updateSettings,
        
        font,
        ...
        enableGestures,
    };

    const context = useMemo(() => {
        return contextData;
    }, [Object.values(contextData)]);

    return <SettingsContext.Provider value={context}>{children}</SettingsContext.Provider>;
};

export default SettingsProvider;