Allow disabling local config saving (one source of truth)

[epheterson]

It's surprisingly difficult and frustrating trying to set this up in the UI and preserving all changes. Each change requires being saved first locally, then separately going back in and saving remotely. Then you must clear the cache to confirm it's saved, which often for some reason it isn't.

For users who don't care for a separate local/permanent config, this dance is very unnecessary. Please allow having a single source of truth, which would simplify updating the config file.

[hppyworld]

why this issue is closed? can we reopen it?

[Lissy93]

Yeah, feel free to submit a PR

[Lissy93]

Hiya @hppyworld @krswin and @epheterson
This is now implemented in #488 / V 2.0.3 :)
You can use appConfig.preventWriteToDisk to prevent changed from being written to disk, and / or appConfig.preventLocalSave to prevent changes from being cached locally.
Hope that helps :)

[epheterson]

This is great, thanks! Just updated it and happy to see the "Save Locally" button disabled. Ironically, it did take a few saves and resetting local settings to stick, but now all good!

Also noticed a little typo on the settings:

If set to true, no users will not be able to save config changes to disk through the UI

If set to true, no users will not be able to save config changes to the browser's local storage

You either need "no users" or "will not" but currently it's a double-negative.

[epheterson]

It's looking like if I don't "Reset Local Settings" then I can never locally apply updates from the config file. Is that by design?

Example –

1. Disable local config by enabling "Prevent saving config to local storage."
2. Reset local settings, reload, verify local save button is disabled.
3. Enable "Widgets always use proxy"
4. Save
5. Reload browser (Shift + Reload on Firefox)
6. Notice no change, try "Reset Local Settings"
7. Changes are applied / config file is re-read from server

[Lissy93]

So that's not actually local storage, just the backend taking a minute to recompile the frontend. You can check the dev tools, specifically local storage (not saved), network request (xhr to save to disk) and console (status is logged there)

[epheterson]

Thanks for explaining, though is there anything that can be done to speed it up? Dashy is great except for the editing flow which leaves you waiting to see your changes, sometimes leaving you wondering if they saved at all.

[Lissy93]

It's VueCLU which is slow. These architectural changes would need to be made:

• Have changes read from file on the fly (not compiled)
• Rewrite backend in Go, instead of Node.js

[ghost]

The edit workflow is really a bit scary if not saved correctly automatically as usual. Dashy shows the message: "Saved to Disk" after saving. At this point there should be a hint what happens now or that you have to wait or something. When I press F5 everything is gone... Uploading a backup every time can't be the right way.

Do I understand correctly that you should wait 1 minute after pressing "Save to Disk"?

[epheterson]

Hate to say it but I switched to Homarr and this is the primary reason. Saving should be simple and immediately verifiable.

[ghost]

I give it another go because what Lissy93 has created here is really really great :) except of editing ;)

[Lissy93]

I have been working on a totally new unified config loading method past few days. Should be ready in a week or two.
That will mean that a rebuild is no longer necessary (which is what is taking a few mins), and also mean that you can more easily and safely manage the config through the UI.

The reason it's so confusing atm, is because I never expected people would want to edit their config through the UI, but it kept being requested, so I added it but the initial config loading method wasn't really designed for it, which is why I'm rebuilding that at the moment :)

[epheterson]

Agree Dashy is great, looking forward to trying it again when the new method comes out! Thanks for all your hard work on it @Lissy93!