/learn Profile Requests and Console Behaviour

Describe the bug

1. It appears a console.log() was accidentally left in the Profile.js script.
2. A request to my/(a user’s) page-data is returning a 404.

To Reproduce Steps to reproduce the behavior:

1. Go to https://www.freecodecamp.org/learn
2. Open DevTools
3. See log true or false in console, due to: console.log(showDonation);

• File: https://github.com/freeCodeCamp/freeCodeCamp/blob/master/client/src/components/profile/Profile.js
• Line 126

1. See error in console as in picture below.

Expected behavior No Errors, no logs.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Chrome
• Version: 83.0.4103.97

Additional Info I believe the:

‘progress updates processed where possible’

Is useful, and should stay.

[raisedadead]

1. It appears a console.log() was accidentally left in the Profile.js script.

Yep, git blame @ahmadabdolsaheb and me for missing it in the QA. Reference: https://github.com/freeCodeCamp/freeCodeCamp/blame/f6aaa5f38a37c6739291ca51790a1e660aec182c/client/src/components/profile/Profile.js#L126

A PR is welcome to remove this and any other rogue logs.

1. A request to my/(a user’s) page-data is returning a 404.

This is an expected side-effect of us using Gatsby’s routing to query and get the user profile available at /your-username.

Essentially, when you hit /some-path, we first let Gatsby check in the static files if something is available at that path, if not we query the API to lookup there for a username. If both conditions fail, we would render an actual 404 page.

But for this to work the status code 404 is sort of abused. Its hacky but there is no way around this to the best of my knowledge.

Just to clarify, this should be left as is.

[ojeytonwilliams]

@Sky020 There’s nothing to apologise for. So, my position is just that debugging messages are things that should be shown to developers, rather than users (if possible). Essentially because that information is intended to help find and fix bugs, which isn’t something a user should be expected to do.

In this case ‘progress updates processed where possible’ mostly just indicates that you’ve navigated to a challenge, so I don’t think it’s useful. console.warn('unable to process progress updates', err.message) seems worth showing, but only because we don’t have access to this information with a remote error logger (Sentry in our case).