fix(auth): Make logout into a function

[AntonLantukh]

Description

• Fix UserMenu component in the header
• Fix User component in the cabinet
• Update snapshot
• Update e2e-tests

This PR solves: #37

Steps completed:

According to our definition of done, I have completed the following steps:

• User stories met
• Storybook stories
• Unit tests added
• Linting passing
• Unit tests passing
• Docs updated (including config and env variables)
• Translations added
• UX tested
• Browsers / platforms tested
• Rebased & ready to merge without conflicts
• Reviewed own code

[dbudzins]

Did the history.push get dropped here? Is it possible to just move that to the account store logout function (probably using window.location.href = '/' to avoid problems with hooks)

[AntonLantukh]

@dbudzins Yeah, right after this hook we have one more with history.replace. So it does all the job because the customer (user) gets null value in logout function.

  useEffect(() => {
    if (!loading && !customer) {
      history.replace('/');
    }
  }, [history, customer, loading]);

[dbudzins]

Ah, I see that and it certainly should work as you describe. Do you think it might be easier to read / follow / update the code if the navigation lived inside the logout function though? For example if someone wants to change the post-logout page or let users stay on the same page after logout? Alternatively, if you want to leave the navigation in the hook, can you add a comment that this returns the user to the main page after logout and also remove the history.push in UserMenu?

[AntonLantukh]

@dbudzins thank you for ideas! I modified the solution a bit and created a new Provider to control page access. And it also does redirect to the base page if the user is not defined. What do you think about this approach?

[dbudzins]

One small point about the history.push, otherwise looks good

[dbudzins]

I think this is a small enough amount of code that it could just be directly in Root.tsx, but this could also eventually expand to have some other user or account related side effects. If you are going to keep it as a provider, it should probably follow the Context.Provider structure like the other providers.

[AntonLantukh]

I changed it back to useEffect hook and left the comment. When I understand all the possibles corner cased I will switch to the provider logic if possible.