UI: Fix settings page route (about, shortcuts)

[lonyele]

Issue: #6741

Summary

Make settings page route properly by changing viewMode state so that only settings page is rendered.

What I did

• Change viewMode state to settings by introducing new api showSettingsPage when it is routed to settings pages(about, shortcuts, and more in the future)
• Persist settings page URL after refreshing the browser by adding fallback logic to setStories
• Add settings to PropTypes temporarily for making console warnings silent(see TODO section below)

More context

Problem

As this was implemented, viewMode has to be changed to settings for rendering only settings page component.

What is missing here(TODO)

I think the following PR is needed to resolve this issue of PropType warnings by getting the lists of possible viewMode from all the registered addons and others for strongly type viewMode.

[vercel]

This pull request is automatically deployed with Now.
To access deployments, click Details below or on the icon next to each push.

Latest deployment for this branch: https://monorepo-git-fork-lonyele-fix-settings-page-route.storybook.now.sh

[lonyele]

Hm... I merged lastest next branch to fix the source-loader.test.js fail. Maybe I messed up something here, because CircleCI is not running...

[lonyele]

or... it went fine. Now CI looks fine and chromatic also looks fine. Would anyone review this one?

[lonyele]

oh wait... I'll write a test for this

[shilman]

@lonyele I'm not thrilled with the idea of adding a new API for this. In general it's better to keep API surface area smaller unless it's needed. That said, the code all looks pretty good to me. @ndelangen what do you think?

[lonyele]

@shilman Yeah... I really didn't want to use setState way instead of just using navigate(...) because all the code was implemented that way. I couldn't find the real cause of this problem.

[lonyele]

OH.... wait I found it.

[lonyele]

Yesss! I've been having this feeling that I almost found it but couldn't really confirm it. What about now!

[shilman]

@lonyele Doesn't this change fail to change the viewMode?

[lonyele]

No! I made the new api because I wasn't sure the place where assigning value to viewMode. However I confirmed that parsePath is the very first place where assigning value to viewMode

The reason why this bug happened is because settings viewMode was excluded from assigning value thus always return undefined which makes viewMode at the component level always become a story. At the end, url is /settings/about but viewMode is story thus showing both story preview component and settings page component.

const knownNonViewModesRegex = /(settings)/;
export const parsePath: (path?: string) => StoryData = memoize(1000)(
  (path: string | undefined | null) => {
    const result: StoryData = {
      viewMode: undefined,
      storyId: undefined,
    };

    if (path) {
      const [, viewMode, storyId] = path.match(splitPathRegex) || [undefined, undefined, undefined];
      if (viewMode && !viewMode.match(knownNonViewModesRegex)) {
        Object.assign(result, {
          viewMode,
          storyId,
        });
      }
    }
    return result;
  }
);

While I was trying to change different parts of the code, I got lost on the real cause of this problem. It's good that I finally found it! Please check now deployment!

[shilman]

Awesome. Thanks for seeing this through!! Great fix 👏