UI: Redesign/organize settings page #753

As mentioned, the settings page is rapidly getting cluttered with different sections. The Save button is also in an awkward place as only some settings needs to be manually saved. I think a better design would be to have sections on the left side, and the main pane shows settings of this section only. The "Save" button can then appear only if that page needs to be saved.

I personally prefer to always show the monitor list, what do you think if implemented like this:

I think it works for GitHub because there is a clear hierarchy of "most of the time you only need code, issues, and PRs" and they can just hide the rest as the screen width changes. But we don't really have that, and I also rarely see settings sub-pages get separated into tabs like that. How about we split the settings pane itself then?

I think it works for GitHub because there is a clear hierarchy of "most of the time you only need code, issues, and PRs" and they can just hide the rest as the screen width changes. But we don't really have that, and I also rarely see settings sub-pages get separated into tabs like that. How about we split the settings pane itself then?

This is unexpectedly better looking than I thought. Let's take this way.

I personally see UK as about 3 key features, the monitoring, the notifications, and the status pages, and I am wondering if notifications should get their own section like the dashboard. Should #233 et. all, be accounted for and space prepared ahead of time while the settings are getting updated? Or should that be delegated to a separate PR? (I assume the latter, but worth bringing up.)

Are you talking about adding a completely new page to manage notifications settings? IMO a lot of them are and will be "per monitor" rather than global, so I don't see the need. Also, the status page currently manages its own settings. It would be debatable if in the future "multiple status pages" becomes a thing, the settings page be a place to manage it. But I'm also not sure. But this refactor would at least convert each settings sub-section to its own component, so future expansion would be easier and more organized.

@chakflying's implementation is preferred.

@louislam still working through this, but using $parent.$parent.settings already seem like a phenomenally bad idea. Do you think each settings sub-page should manage its own state instead?

@louislam still working through this, but using $parent.$parent.settings already seem like a phenomenally bad idea. Do you think each settings sub-page should manage its own state instead?

I think we can put into a function that returns $parent.$parent.settings in this stage.

Tested the tests work locally, but it fails on GitHub for seemingly no reason...

Tested the tests work locally, but it fails on GitHub for seemingly no reason...

I had similar experience, I found that jest + puppeteer is really hard to use especially on GitHub Action, because their machine is too slow.

I think it's finally fixed.

@louislam I think I found a bug while writing tests that "Disable Auth" currently breaks the settings page because of #772. jwtDecode would fail since the token is set to autoLogin. I can add a fix here, or if you think you won't merge this soon we can add a separate fix first.

@louislam I think I found a bug while writing tests that "Disable Auth" currently breaks the settings page because of #772. jwtDecode would fail since the token is set to autoLogin. I can add a fix here, or if you think you won't merge this soon we can add a separate fix first.

Ops, does it crash the whole setting page? If yes, it would be great if we fix it first

Fixed in 95bae8289d3a391065e66673cd969c63b7101ef2