Improve AlertViewer UI/UX

[kpuriIpac]

SUIT PR: lsst/suit#84

• Remove Job Monitor tab for alert viewer
• Default tab when you hit /alertviewer is now the Alert tab (/alertviewer/upload) instead of the Results tab.
• Simplified Results (landing page) text for AlertViewer
  • required a small custom component to modify the bottom section of the LandingPage, I could have probably done this through slotProps, but it was proving to be trickier (was affecting Euclid/Spherex) and LandingPage is used in several places so I thought it was best to create a simple custom component instead in this case
  • And the changes in RoutedApp are to support being able to call LandingPage as well (to have more control over customizing it)

Testing:

• Firefly's AlertViewer: https://fireflydev.ipac.caltech.edu/alert-viewer-changes/firefly/alertviewer
• SUIT's AlertViewer: https://enable-alert-viewer.irsakubedev.ipac.caltech.edu/suit/alertviewer
  • Ensure you're routed to Alert tab directly. Inspect the Results tab (landing page) text.
  • Checkout this branch locally if you want to test submitting Alert IDs (sample IDs: 170112073844916273, 170059278837088375)
  • URL API should still work (if trying on the test builds above, you should get a missing/invalid token error, locally it should take you to the results tab with results loaded).

[loitly]

Please revert customLandingPage changes if my suggested solution works. Thanks.

[loitly]

I don’t think this is necessary. slotProps.landing was created specifically for this use case. If you need a custom component, you can define it like this:

landing: {
    component: <AlertViewerLanding/>
}

[loitly]

Is this logic correct? Normally, ?api would show the api help page, but I am not seeing that happen.
Also, using URLSearchParams might help when working with URL parameters.

const { pathname, search } = window.location;
const params = new URLSearchParams(search);
params.has('api');

[kpuriIpac]

yes good suggestion, thank you. also fixes the ?api bug, it should now show the api help page (after I push my commit).

The if check here was needed because we want to re-route user to /alertviewer/upload path when they try to access /alertviewer, but if I didn't add the check for !hasUrlApi, it would also re-route you to /upload path for the URL API instead of taking you directly to the results (when, for instance, you try to access somethign like: /alertviewer?api=alert&id=170059278837088375).

open to better suggestions for this re-route logic though.

[robyww]

UI changes look good. Go ahead and merge when @loitly approves.

[loitly]

Looks good. Thanks for the changes.