DAO-188 Add Policy Select page

[mcoetzee]

What does this change?

• Adds the Policy Select page, which is very similar to the My Policies page. It only shows active policies, and doesn't give the user an active/inactive filter
• Links to the Policy Select page from the My Claims page, except when there is only one active policy, then we navigate directly to the Policy Details page
• Adds a BackButton component that uses onClick={() => history.goBack()} (i.e. it works like the browser's back button). Advantages include:
  • preserving search params when you go back (My Policies and Policy Select pages use query, filter, and page search params)
  • preserving scroll position when you go back
  • not needing to keep track of where you came from on pages that can be linked to from multiple places (Policy Details page is linked to from 3 different pages atm)

How did you action this task?

Policy Select page I moved all components from src/pages/policies -> src/components/policies, to be reused by both the My Policies and Policy Select pages.

BackButton component For UX purposes, we want to prevent the BackButton from going back (via history.goBack()) if the BackButton is present on the first page the user visited (i.e. the app entry page). Otherwise if they visited a website in the same tab before opening the DAO dashboard, it would navigate back to that website. The solution was quite simple, and it was to identify the app entry page with window.history.state (the HashRouter doesn't support history/location state):

const App = () => {
  useEffect(() => {
    // When the app mounts we want to identify the current page as the one the user first visited
    // (i.e. the entry page), so that if the custom back button is present on the entry page,
    // that it knows that it can't go back.
    identifyAppEntryPage();
  }, []);

export function identifyAppEntryPage() {
  // We use session storage so that if the user refreshes the browser tab, that we don't
  // identify another entry page
  if (window.sessionStorage.getItem('hasIdentifiedAppEntryPage') !== 'true') {
    // The HashRouter (from react-router) doesn't support history/location state: https://v5.reactrouter.com/web/api/HashRouter
    window.history.replaceState({ appEntryPage: true }, '');
    window.sessionStorage.setItem('hasIdentifiedAppEntryPage', 'true');
  }
}

And then we can figure out if we can go back or not:

export default function BackButton(props: Props) {
  // We can go back if we are not on the first page the user visited
  const canGoBack = !window.history.state?.appEntryPage;

Screenshots

[linear[bot]]

DAO-188 Active Policy Select page

A new page to navigate to when the user clicks the New Claim button on the My Claims page. The page only lists the user's active policies.

[Siegrift]

I am 95% sure I left one more comment (but I don't see it here). I was thinking we should not have the policies components moved inside the components folder but instead have it in pages similarly to proposal-commons. My intention was that components are to be the generic building blocks for the UI and all domain specific stuff should be in pages (which is a bad name looking at it now).

[mcoetzee]

I was thinking we should not have the policies components moved inside the components folder but instead have it in pages similarly to proposal-commons. My intention was that components are to be the generic building blocks for the UI and all domain specific stuff should be in pages (which is a bad name looking at it now).

Yeah the lines are always a bit blurry when folder structure is the topic.

When I first started exploring the codebase, pages/proposal-commons gave the impression that it was a page itself:

pages/
  |- ...
  |- proposal-commons/
  |- proposals/

So tbh, I'm not too keen on a pages/policy-commons, but I do get what you are saying about keeping src/components more generic. Another option that I would be more keen on looks like this:

components/ (generic building blocks)
pages/
  |- ...
  |- components/ (domain specific building blocks)
    |- policies/
    |- proposal-details/
    |- proposal-list/
    |- ...
  |- my-policies/
  |- proposals/
  |- ...

wdyt?

[Siegrift]

When I first started exploring the codebase, pages/proposal-commons gave the impression that it was a page itself:

Yep. It initially all started with all pages bing pages (and related components were in a page subfolder), but then we started to reuse proposal specific components in multiple pages so it was awkward to have them import from another page, so I moved the common stuff (proposal-commons) alongside.

Another option that I would be more keen on looks like this:

Yeah, that feels ideal to me.

[mcoetzee]

Ok cool, reckon I will create a separate task for this (and keep this PR's folder structure as is so that the PR doesn't bloat)

[Siegrift]

Ok cool, reckon I will create a separate task for this (and keep this PR's folder structure as is so that the PR doesn't bloat)

Yeah, that seems better.