feat(Effects): add OnInitEffects interface to dispatch an action on initialization

[timdeschryver]

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?

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

What is the current behavior?

As mentioned in the issue, the solution we have now to dispatch an INIT effect action doesn't work in prod builds because the constructor name is mangled.

Closes #1447

What is the new behavior?

This PR adds a new lifecycle hook OnInitEffects that dispatches a user-defined action on effect registration. I couldn't find another way to access the effect's name.

Personally, I also find this solution to be cleaner and more flexible than the previous one.

Right now I've made it so that only one action can be dispatched, but this can also be an array of actions if it's needed. Imho one action is sufficient and also follows our best practices to treat an action as a unique event.

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

The first commit reverts #1305
The second commit adds the OnInitEffects hook. In this commit, I also changed the OnIdentifyEffects signature to be consistent with the other signatures.

[timdeschryver]

Changed this signature to a "normal" function instead of an arrow function.
If we would use an arrow function, the function isn't being picked up at

platform/modules/effects/src/effect_sources.ts

Line 68 in 705e29b

if (

.

[timdeschryver]

Fyi, it seems like the failing test command is "because" of yarn - yarnpkg/yarn#6746 and will be fixed in the next release.

[brandonroberts]

@timdeschryver instead of introducing a new hook, how about adding a configuration when registering effects to give the set a name? It could be the same as the class name, but we would use the array of names with the UpdateEffects action.

[timdeschryver]

I think the downsides of using that approach are:

• With only a name, a user couldn't define a payload, if this is needed
• It won't be possible to trigger an init while manually adding effects, but is this even needed?

The better part would be, that it would be consistent with the config from ngrx/store.

[brandonroberts]

Yea, I thought about manually adding effects but I think that's an advanced use case. I'd rather provide the name and use a consistent Update action then have to come up with a different one for each effect.

[brandonroberts]

Scratch that last comment. I wasn't thinking about how the effects are registered with more than one class. I'm good with the init function.