Offer an option to reset local settings if loading them fails at launch

[anttimaki]

If SettingsLoader fails to load the settings, a button for clearing out the IndexedDB containing local settings is shown. Also offers different suggestions for solutions based on what went wrong.

Refs TS-1384

[anttimaki]

If loading the info of default game (RoR2) fails:

If loading the settings fails the first time (this was achieved by putting a non-JSON string in the storage):

If user clicks the reset button, but the resetting itself fails:

I'm not sure if we want to use link here. It's easier for the user than copy-pasting a long URL, but it's opened in another window spawned by the mod manager rather than user's default browser.

If resetting IndexedDB succeeds, but the settings still can't be loaded:

Any suggestions for better wording etc. is welcome.

[anttimaki]

Here's a video of how things should ideally work. The modal is trickered by reloading the app via dev tools (because it was easier for me to record the video this way) and having the code intentionally corrupt the storage on first load attempt.

r2modman_reset.mp4

[MythicManiac]

Not a full review yet, but could the button use the styling that's used elsewhere in the app? I'd assume some fairly easy to re-use classes exist for that.

[MythicManiac]

Main question here, didn't review the smaller details yet

[anttimaki]

@MythicManiac

• The button now has rounded corners and padding that's consistent with the rest of the buttons. The buttons offered by Bulma mostly looked off when set on the red background, so the button is still white.
• The settings database is now dropped using IndexedDB API directly. For now I chose to not require a restart, since it didn't seem necessary. Thoughts?

[MythicManiac]

Looks good enough to me, left a comment but I don't consider it a blocker

[ebkr]

Added comments primarily regarding wording

[ebkr]

This will if a custom data directory was set. I need to work on a way to re-link easily as currently it expects an empty folder.

[anttimaki]

Removed that line.

[ebkr]

Preference to avoid things like "Well, that's awkard" as it adds no value and is just clutter

[anttimaki]

Removed.

[ebkr]

Any reason for noopener / noreferrer?

Can we bind the Link component provider earlier (if it needs binding?) as that can open in an actual browser

[MythicManiac]

Any reason for noopener / noreferrer?

Generally good practice, there are some security concerns with links that don't use these.

Not sure about the Link component suggestion, leaving that up to @anttimaki

[anttimaki]

My idea was that the SettingsLoader mounts before any providers etc. to reduce points of failure, and to ensure that any problem encountered is actually related to loading the settings. If having the link open in a browser is considered worth it to introduce the LinkingProvider earlier, and the LinkingProvider is seen as a stable and tested implementation, I see no reason why it couldn't be done. Personally I don't see it fitting into the idea (that I had) of the SettingsLoader, though.

[MythicManiac]

That makes sense to me at least, given that the goal was to minimize the points of failure for this component.

[ebkr]

I think it’d be good to do, and it’s stable as in it only depends on external libraries for opening, it’s not reliant on settings or anything user accessible

[anttimaki]

This is now passed to SettingsLoader as a prop to keep things consistent with logError. Also skipped the provider and used the implementation directly so that all the providers are initiated in the same place (App.vue).

[ebkr]

See previous comment about wording, I think we want to avoid "friendly" wording and to keep it more professional and straight to the point

[anttimaki]

Removed.

[ebkr]

Left it as comment by accident 👀

Requested changes have been addressed and approved by MythicManiac