feat(StoreDevtools): implement actionsBlacklist/Whitelist & predicate

[Wykks]

Ref: #938

Note: the unit tests doesn't test jump / slider (I'm not sure how to test that).

There an issue when using the slider (and the action filter feature).
The app doesn't get the right state (whereas the extension show the correct state).
To reproduce in the example app, add actionsBlacklist:

    StoreDevtoolsModule.instrument({
      name: 'NgRx Book Store DevTools',
      logOnly: environment.production,
      actionsBlacklist: ['\\[Book\\] Search$']
    }),

Do two different search, then, jump or slide back to the previous Search Complete.

Sorry for leaving this issue here, I spend more than half a day figuring out how this works... This is as far as I'm able to do, for now... I'll try to investigate more If needed, but you probably already know what's going on 😅

Edit: Ok I see what's going on. Since I filter the liftedState only for the devtoolsExtension.send, the currentStateIndex send by the extension is desync with the internal liftedState.

I could actually filter-out the state outside extension.notify but according to: zalmoxisus/redux-devtools-extension#316 (comment) , the internal liftedState should not be filtered.

Edit 2 : Welp, I guess I should filter the state outside extension.notify after all. It works fine. But I'm a bit puzzled about how to "properly" code this. I'll update the PR next time (maybe tomorow).

[coveralls]

Coverage decreased (-0.4%) to 88.385% when pulling 122a342 on Wykks:master into 49dcf7f on ngrx:master.

[dummdidumm]

You could add a new property filteredOutActionIds to the reducer, which contains a list of action ids that should not appear on the monitor. That way, internally, the reducer keeps the filtered out actions and can properly recompute states. It also can use this array to compute an offset for the maxAge and for the "jump to state"-feature.
Inside extension.notify, the array is used to filter the actions/states and then pass it to the redux-devtools.

[brandonroberts]

Thanks for the PR @Wykks! As an alternative, I'm looking into sending all actions/states through the extension since it already has support for blacklist/whitelist/predicate and I don't think we need to duplicate all that on our end.

[buenjybar]

👍 something like this will be nice !

[kevinahuber]

@Wykks Any word/work on this? Happy to help get this through.

[Wykks]

Hi!

Sorry for this very long silence... I totally got demoralized doing this PR.
I can't help thinking that something is really wrong.

Just like Brandon said, this should be handled by the extension itself. But it doesn't work when sending the full state (with this.devtoolsExtension.send); because the extension doesn't filter anything in this case. That's why I started to handle both cases.

But, I really don't get why it's implemented like that in the extension. This should just be a visual thing, with some skip when moving through states. There's no actual need to filter the state like that...

[brandonroberts]

@Wykks apologies for getting behind on this one. Will you rebase on master? Handling it here may be the option for now. We may need to open an issue on the extension to at least get some clarification on filtering when full state is provided.

[brandonroberts]

@Wykks will you rebase this one?

[Wykks]

ops didn't saw the last message. I can do the rebase this weekend yep!

[brandonroberts]

👍

[Wykks]

Rebased and updated!
Same thought on this stuff since the last time I spent time on it; it doesn't feel correct but it works.

[brandonroberts]

@Wykks will you rebase again? Thanks

[Wykks]

Done, sorry for the delay..

[brandonroberts]

🎉

[wendelstam]

Really nice addition. In what version will this be included in the NPM package?

[timdeschryver]

It will become available in the next version (7).
You can use it now by using the nightly builds.