How to disable the logging of a controller action for a given controller/action?

[gremo]

I'm listening to the scroll:progress event (emitted by me) and invoking class-mutator#update. The action gets logged when debug is enabled, and this is fine in many cases.

But in this case the console is flooded with a lot of messages (depending on the monitor refresh rate). How can I disable the logging for this particular action?

<div data-controller="class-mutator"
    data-action="scroll:progress@window->class-mutator#update">
</div>

[marcoroth]

I don't think you can disable the logging on a per controller/action basis.

But I think you should anyway either debounce the invocation of the controller action or debounce the emitting of the custom event itself so that the action doesn't even get triggered so many times. Usually you don't have to react to every single event if you have so many invocations in such a short time. There would be a few ways to achieve that:

For debouncing the emitting of the event:

• write your own debounce function using setTimeout()
• use lodash debounce

Listen to a debounced version of your emitted event:

• use debounced and register your custom event to limit the amount of controller action invocations

<div data-action="debounced:scroll:progress@window->class-mutator#update" ...>

Debounce the Controller Action itself:

• write your own debounce function using setTimeout()
• use useDebounce from stimulus-use (though I think this will still log the debug messages because the action is debounced inside the controller

I hope this helps! I'm not sure if it's worth having an API for disabling the debug logging on a per controller or even action basis.

I'd be interested to hear what others think, maybe we could look into disabling it via a data-attribute.

[gremo]

Hi @marcoroth yeah I know. Was a borderline example for sure, but there are many cases where this actual feature would be useful. For example, listening to mouse movements and triggering actions.

Or, like in my example but much more simple: do something when the user scroll "up", "down", "top" or "bottom" like hide/show a navigation bar. When you are just scrolling the site for developing purposes, having a lot of messages logged doesn't help.

EDIT: even debouncing scroll for a 200ms wait will cause a lot lot of messages 😄

[lb-]

A potential way forward here.

Stimulus adds logging levels to the existing logging system. Currently the debugLogger can be quite noisy as it logs all non-error activities.

stimulus/src/core/application.ts

Line 95 in a2a030f

logDebugActivity = (identifier: string, functionName: string, detail: object = {}): void => {

Maybe method calls could be a lower debug level compared to controller connection/disconnection?

Then you could be backwards compatible with application.debug = true for all levels and then add support for something like application.debug = 3.

Alternatively logging can be tagged and you pass an array application.debug = ['connect', 'disconnect'].

Examples

• Ruby on Rails logging levels - https://guides.rubyonrails.org/debugging_rails_applications.html#log-levels
• Django logging levels - https://docs.djangoproject.com/en/4.1/topics/logging/#topic-logging-parts-loggers
• JS Console levels - https://developer.mozilla.org/en-US/docs/Web/API/console

Note - I think that debug as it's built is useful for an intentionally noisy output of everything. This is probably not something that should be on by default but only turned on when you need to dig into something more complex.

An idea I have had for some projects is to add an event listener that will enable debug easier when needed but not always have it on. Note - this assumes you don't want to add the Stimulus application to a global.

/**
   * Allow any custom code to trigger debug mode easily.
   */
  window.addEventListener('wagtail:stimulus-enable-debug', () => {
    application.debug = true;
  });