What more savior does a developer need?Photo by Markus Spiske on UnsplashUnlike alert(…), console.
log(…) doesn’t block page rendering and it doesn’t come as a pop-up nor does it appear within our page’s view, so, it is the most used and most loved by developers.
The results from console.
log(…) are only visible in the console of your browser (chrome, Firefox, etc.
).
WHY SHOULD I DEACTIVATE console.
log(…) IN PRODUCTION?Well, if this question is in your head, I guess it means you’re not dogmatic and you’re inquisitive.
If its not in your head, it doesn’t mean otherwise : )When debugging or making sure APIs or other resources are working well, we tend to log a lot of information into the console, including data that errrr… should be hidden (at least without unnecessary diggings by evildoers or over inquisitive users).
If you are like me, then it is only normal you use console.
log(…) a lot and forget to remove them (at least not all) from your codes.
Now, imagine you visiting a website and seeing a bunch of logged data in your browser’s console, apart from it being messy LOL… it gingers you to start looking for what isn’t lost : )My advice is therefore either go through your code properly and remove all the console.
log(…)s within your code-base or just deactivate it at the top.
Photo by rawpixel on UnsplashHOW TO DEACTIVATE console.
log(…) IN PRODUCTIONIf you got here, I’m assuming I have been able to convince you to make sure console.
log(…) is deactivated on your production server.
Here’s how to go about that:Make sure your application has an environment variable that differentiates a staging environment from a production environment: For example, in Laravel, you will be using an .
env file to store environment variables, and there is a variable that differentiate environments (APP_ENV=local/staging/production)Now, within your page before the importation of your custom js file, you should overwrite the console.
log(…) function if the APP_ENV is set to production.
Take a look at the snippet below.
You must be angry at me for taking you through a long read just to show you the magic of an equal to sign.
My bad, just had to make sure you got why this should be used.
BREAKDOWN OF THE SNIPPETThe snippet assumes we are dealing with an application with a PHP back-end.
Same logic can be applied with other languages, so far you have environment variables set.
variable env retrieves and store the ENVIRONMENT (local/staging/production) you might have saved with PHP.
Then a check is put in place through a conditional statement to check if your app is on the production server (as set by you),if that is true, it overwrites the console.
log function and sets it to a redundant and empty function.
Thus, invalidating every usage of the function in codes below it.
NB: this must be placed above all your custom JS codes.
Now you are rest assured your console.
log(…) will work properly on your local or staging server but will not output anything on your production server.
Comments, suggestions or corrections are welcome.
Thanks!Click the link below to learn how to create an environment variable file in a PHP application.
https://medium.
com/@hfally/how-to-create-an-environment-variable-file-like-laravel-symphonys-env-37c20fc23e72.. More details