Codesandbox-client: Hiding console by default can lead to missed warnings

[eps1lon]

🌈 Feature

In React (and 3rd party libraries) warnings are oftentimes logged to the console that show actual issues with your code (without crashing the app).

When landing on codesandbox the console is collapsed by default which makes it easy to miss these issues. It would be nice if codesandbox would be opinionated about the default state of console. Either show it by default for React sandboxes or open it as soon as warnings/errors are logged and the user didn't explicitly collapse it.

[flickz]

@garethx Can you assign me to this issue?

[flickz]

Looking at this issue again, does it not matter we have badge indicating number of unread errors and warnings?

[eps1lon]

It does matter but it's easier to miss. IMO if you open a codesandbox or cause a warning/error you'd always want to see the error.

[CompuIves]

We have an option for the devtools to be open by default (like we do with the container sandboxes with the terminal), but it does take up quite some screen space. Maybe there's a middle way? Maybe we can open the console once there are warnings, or we should maybe show a better indication?

[eps1lon]

Maybe we can open the console once there are warnings, or we should maybe show a better indication?

That's what I suggested and prefer. IMO I don't see a reason to have the console collapsed if there are errors. Maybe other ecosystems treat them differently but React puts a lot of effort into only issuing them if there is an actual problem that can be fixed.

We have an option for the devtools to be open by default (like we do with the container sandboxes with the terminal)

My concern here are non-regular or first-time users. An option that requires knowledge and multiple steps to setup does not improve the situation for this group. Even I didn't know this option existed and it's still unclear to me where this option is and whether it is a user or sandbox option.

[CompuIves]

My concern here are non-regular or first-time users. An option that requires knowledge and multiple steps to setup does not improve the situation for this group. Even I didn't know this option existed and it's still unclear to me where this option is and whether it is a user or sandbox option.

Ah yes that makes sense. I was thinking of enabling this option by default, right now it's not exposed.

But I definitely think that auto-expanding on error is worth exploring. The only thing I'm worried about that it might be confusing for the user as well, since there's no interaction that triggers the animation. That's why I think that making the error indication more clear would also be worth exploring. I'm curious what @DannyRuchtie thinks on this.

[flickz]

@CompuIves @eps1lon
I was experimenting with this code in addMessage:

if (method === 'warn' || method === 'error') {
      this.props.openDevTools();
    }

From what I observe:

• The experience is better off with just "errors"
• When the error is fixed, it should close automatically (still haven't figure where to plug hideDevTools to achieve this)

[github-actions[bot]]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[eps1lon]

Bump

[SaraVieira]

Hey

I will be closing this for the same reason as it was stated on the PR: https://github.com/codesandbox/codesandbox-client/pull/4198#issuecomment-633930227.

This would be super confusing for some users and even cause problems in people who have motion sickness as it's unexpected motion

Sorry and I hope this makes sense

[eps1lon]

The idea was that this would be the default view if warnings are logged on the initial render. Arguing that this is an interaction is just arguing for the status quo. The user wouldn't be aware that another "thing" happened. Just that the default view is different.

[SaraVieira]

But everytime you start any react or vue app you get a warning about the devtools and the user would not be able to have it closed by default

I do agree this could be an option but not the default behavior

[eps1lon]

the user would not be able to have it closed by default

That is the point. In React you almost always want to fix that warning. The issue was that beginners often miss these which is why it should be the default behavior. If you don't care about warnings you can disable it.

I do agree this could be an option but not the default behavior

But in the end you closed anyway.

[SaraVieira]

You can't fix that warning because you are in CodeSandbox, you already have the dev tools but you react doesn't recognize them. It's an invasive workflow, it may not be for you but it will be for many.

If you are a begginer you a lot of the times do not know how to turn off warnings

About the closing, I am closing all the feature requests and adding them to our backlog if we see that the feature request would be something that would benefit the community at large or a small percentage without making the experience worse or unexpected for the rest

I will go over this with everyone and let you know if it gets added

[christianalfoni]

Could we not make it an option in the preferences? "Open console on warnings and errors"?