feat(stark-core): add support for deep state navigation for states from lazy loaded modules. Adapt Showcase to make DemoModule and NewsModule lazy loaded

[christophercr]

ISSUES CLOSED: #810

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/NationalBankBelgium/stark/blob/master/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[X] Feature
[ ] Code style update (formatting, local variables)
[X] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: #810

What is the new behavior?

• The logic to navigate to the Login/Preloading state is now in the StarkSessionModule in "stark-core" where it belongs.
• The definition of the starkAppInitStateName and starkAppExitStateName is now in the StarkSessionModule in "stark-core" where it belongs.
• The targetRoute resolve from the starkAppInitStateName now checks if the target state is part of a lazy module. In that case it lazy loads the module first and then search for the right target state.
• Adapted some UI components to import the Angular CommonModule instead of the BrowserModule and BrowserAnimationsModule, since those modules should be loaded only once in the app.

Does this PR introduce a breaking change?

[ ] Yes
[X] No

Other information

Adapted the DemoModule and NewsModule in the Showcase to make them lazy loaded modules.

[coveralls]

Coverage decreased (-0.04%) to 91.388% when pulling 6589846 on christophercr:feature/stark-session-lazy-loading-support into 94eb491 on NationalBankBelgium:master.

[SuperITMan]

Has Prettier been runned on this file ? Could you reformat this ? 😊

[christophercr]

Yes, in fact it was prettier the one that changed this line ;)

[SuperITMan]

Why having the views: {"@": {}} here ?

[christophercr]

Well, because now that we implemented lazy loaded modules, the states graph was not correct and any navigation to lazy loaded modules failed.

So, I had to adapt the graph: basically I added the AppComponent as the root state of the app, so that means that the <ui-view> is no longer in the root Ui Router state but in a child route, therefore the views: { "@": { component: xxxxx } } is needed to render the page in that ui-view.

This is how the states graph looks now:

[SuperITMan]

Can't we simply declare our states as before like this:

{
  name: "demo.action-bar",
  url: "/action-bar",
  component: DemoActionBarComponent
},

? 😊

[christophercr]

Nop, we need the views: { "@": { component: HomeComponent } } construct, see my previous comment.

[SuperITMan]

Why declare url: "^/news" here and in demo module, declare url: "^/dropdown" ?

[christophercr]

?? I don't think we have url: "^/dropdown" in the demo module... we do have url: "/dropdown".

In any case, if you are wondering about the ^, that is used to avoid double slash "//" in the URL after the domain (https://github.com/angular-ui/ui-router/wiki/URL-Routing#absolute-routes-). Otherwise, when we navigate to a demo page we will have a URL with double slashes (http://localhost:3000///demo/somePage") 😕

[SuperITMan]

@christophercr could you please rebase your PR ? 😊

[christophercr]

Rebased 😉