Should logger log in process.env.NODE_ENV === test?

[oliviertassinari]

Noticed it with oliviertassinari/material-ui@9a3c143.

[dtassone]

I think it can log from the info level. So it's less verbose and we can understand a bit more where it fails

[oliviertassinari]

I was looking that the console on the storybook side, the debug and info messages hide the other important warnings and errors.

What about the following plan?

• We don't log debug nor info by default, nor in people's applications, nor in our tests, nor in the storybook.
• We allow developers to opt-in for debug and info levels.

[dtassone]

How about we set the default level to warning?
If a user use the grid and don't see the warning or errors of the component, it's not great.

How do you want to opt-in?

[oliviertassinari]

How about we set the default level to warning?
If a user use the grid and don't see the warning or errors of the component, it's not great.

Agree! I was under the assumption that we use console.warn and console.error directly for these feedback, bypassing any abstraction.

How do you want to opt-in?

I think that it depends on the use cases. Maybe?

• If it's for internal development, we could imagine an env variable or a localeStorage variable.
• If it's for our users, we could image a prop too.

[dtassone]

Users have the option to pass their own logger, in the case they use a database or something like seq or splunk...
The default logger used by the grid is console. So by default it does console.warn but it can be overwritten to work with a real logger.
They can also set the minimum level they want the grid to log.

If it's for internal development, we could imagine an env variable or a localeStorage variable.

It already does that. If you add DEBUG in your local storage, it overrides the environment conf and start logging.

What are we trying to achieve here?
Should we just change the default log level to warn?

[oliviertassinari]

What are we trying to achieve here?
Should we just change the default log level to warn?

This would be great :). It would solve the flooding pain point and be enough to close the issue.

---

Users have the option to pass their own logger, in the case they use a database or something like seq or splunk...

Interesting, would it be used for remote debugging? For this use case, I was expecting that developers would hook into the native console calls and record all the events. To make sure they don't miss any from other parts of the UI.

[dtassone]

Well I have not come through the practice of overriding the console to get the component logs. Usually library or component logging get dropped and forgotten as we expect libraries to work...
I've used https://github.com/trentm/node-bunyan in the past which was pushing to our seq interface https://datalust.co/

[oliviertassinari]

I never had this case in the browser, so I can't tell. I also didn't benchmark what alternative UI libraries have for logging. Let's see and explore how that custom logger will turn out :).

The closest I was in the past, was with Sentry, they wrap EVERYTHING, we would use the console logs recorded to debug exceptions. On node.js side, I have tried node bunyan but their decoder wasn't forwarding the right system signal for our docker instance cleanup to work correctly. We went with a custom implementation and an adapter for ClouldWatch on AWS.

What problem were you solving with Seq? I mean, how was it used to improve the final application?

[dtassone]

It was used in support for example, to track user actions on the app.
It was also used on the backend so we could track the full user journey.