Store: 🚀[FEATURE]: Ignored Actions in Logger Plugin

[armanozak]

Relevant Package

This feature request is for @ngxs/logger-plugin

Description

The logger plugin does not have an ignored actions list option. It either logs every action or does not log any action at all.

Describe the problem you are trying to solve

Some actions are simply fired too often or not really the actions you, as developer, want to focus on or debug. When they are logged too, the console becomes cumbersome.

Describe the solution you'd like

Passing a list of actions to plugin options which will be used for filtering some actions out before logging. The filtering function should probably be memoized in order to avoid overhead (although there may be some eventually).

Describe alternatives you've considered

I have considered passing a custom logger via options, which is currently available, but that is not really practical.

Another option is whitelisting instead, but it does not seem to be as practical as using a blacklist in this case. Additionally, backwards compatibility requires all actions to be logged if a list is not provided and that alone may be confusing.

[markwhitfeld]

I think that we should add an optional filter to the options.
The filter would have a normal predicate signature: (action: any) => boolean.
If it returns true then the action would be logged.
If the filter is missing then all actions would be logged (as long it is not disabled).
PS. The memoization could be handled by the implementer of the function.

What do you think?

[armanozak]

I think this is a much better idea than just getting a list of actions to ignore. 🙂

Nevertheless, some people will have difficulty in creating performant functions to filter actions. So, I suggest exporting predefined memoized functions for simple filters . For example:

NgxsLoggerPluginModule.forRoot({
  filter: LogFilters.Blacklist([SomeAction, SomeOtherAction])  // will not log given actions
})

-- or --

NgxsLoggerPluginModule.forRoot({
  filter: LogFilters.Whitelist([AnotherAction])  // will only log given actions
})

LogFilters.Blacklist and LogFilters.Whitelist are higher order functions here.

BTW, we can also consider implementing the strategy pattern.

[joaqcid]

what about blacklisting at the @Action level ?

we could add a log: false to the ActionsConfig and control which actions to exclude from logging

[markwhitfeld]

I think that I would prefer to provide copies of those performant functions as examples in the docs than include it in the library api at this stage.
Would you like to work on the PR for the filter?

[joaqcid]

i dont have bandwidth at this moment :(, but looking forward to use this new feature!

[armanozak]

I can start working on this on Monday. Is that OK?

[splincode]

what about blacklisting at the @Action level ? not sure, because it's core API, such functionality should not depend on plugins

[armanozak]

I agree with @splincode. We should not change core behavior. However, I would like to discuss if it is possible to extend Action decorators functionality with another decorator. 😁

[markwhitfeld]

@armanozak That is great thanks!
Please remember to add tests, docs and a short write up in the announcement article for the next version (https://github.com/ngxs/store/blob/master/publication/announcing_ngxs_next/article.md).
👍

[markwhitfeld]

This will go out with the next release (aiming to be in the next 2 weeks).

[armanozak]

Hi @markwhitfeld,

Is the next release soon? Thanks.

[markwhitfeld]

Good news, this has been addressed in NGXS v3.7 which was released last week.
( see https://dev.to/ngxs/announcing-ngxs-3-7-1kbk for release notes )

I will close this issue. Please let us know if it is not resolved.