refactor(example): use featureKey for layout selector

[erhise]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngrx/platform/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

Consistently use feature keys exported from reducer file, e.g. where selectors for underlying state are being created.

[ ] Bugfix
[ ] 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?

Both feature keys and hard-corded values are used.

What is the new behavior?

Declared feature keys are being used in all places where they should be referenced which scope potential name changes to one place.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

[ngrxbot]

Preview docs changes for 4b48e51 at https://previews.ngrx.io/pr2323-4b48e51/

[alex-okrushko]

"use featurekey in all places"
I see only one place that changed :)

[alex-okrushko]

just one generic is fine createFeatureSelector<fromLayout.State>(...)
Typically there is no global State and many features are lazy-loaded, so there cannot be a single interface that connects them all.

[erhise]

If this is to be added I guess it would imply changes to all other places where FeatureSelectors are being created e.g. https://github.com/ngrx/platform/blob/4b48e51f95/projects/example-app/src/app/auth/reducers/index.ts#L29 ??

[alex-okrushko]

I think so, yes. Maybe in the follow-up PRs.
Also, after PR #2325 lands there would be some more changes
@timdeschryver @brandonroberts hope you don't mind.

[timdeschryver]

The 2 generics are there to provide type safety, but you have to extend the Feature state with the Root State:

export interface State extends fromRoot.State {
  [booksFeatureKey]: BooksState;
}

But this was before the usage of feature keys.

I think we could indeed refactor this, but I don't got a strong opinion on this.

Sometimes it will still be needed to extend from the root, this is when you're combining selectors from the feature with the root.

We can take this one in a later PR and merge this PR if everything is OK with it.

[alex-okrushko]

Sometimes it will still be needed to extend from the root, this is when you're combining selectors from the feature with the root.

There are workarounds for this :P

[timdeschryver]

@alex-okrushko see 691189f for the original commit.

The changes that were made were (but are now reverted):

export const selectAuthState = createFeatureSelector<State, AuthState>(
  authFeatureKey
);

export const selectAuthStatusState = createSelector(
  selectAuthState,
-  (state: AuthState) => state.status
+  (state: AuthState) => state[fromAuth.statusFeatureKey]
);

But I'm not a big fan of using the feature keys for createSelectors. See the conversation we had at #2323 (comment).
Pinged you and Brandon to hear your thoughts on it.

[alex-okrushko]

But I'm not a big fan of using the feature keys for createSelectors

100% agree. Feature keys only for createFeatureSelector which sets the type of the rest of selectors for a feature.

[brandonroberts]

I agree also. Let the types flow from the top

We will tackle this in follow-up PRs after #2325

[timdeschryver]

Thanks @erhise