May 22, 2017
May 22, 2017
A couple days ago I was working at a client’s office, pair-programming alongside the coolest dog I’ve ever met, and I got asked a simple question: what’s the proper way to log in React Native?
I gave it a bit of thought and wrote down what logging options we get in React Native straight out of the box and whether we need anything else.
Before we dig into various ways of writing to our application log, let’s go through the options where we can read them first.
Writing logs is simple — whatever you output to the console log, it’ll get displayed in the application logs, both in the remote debugger as in the device logs that React Native (or Xcode / Android Studio) show us.
There’ just one thing I want to draw your attention to: using the proper log level. Apart from console.log we also have console.warn, console.info, and console.debug. It makes sense to use all of this diversity, so I use them for different purposes:
I use console.warn when something unexpected happens. Those could be edge cases that I haven’t gotten round to implementing yet,or a server response that technically isn’t completely wrong, but definitely looks fishy.
Console.info is for letting me that particular events that I expected to happen went on as expected. For example, I might want to log list items one by one as they’re being (re-)rendered.
Finally, console.debug means that it’s just a temporary (meaning I’ll remove it as soon as I figure out what’s going on) log that I need for my problem-solving process. Those won’t be even committed to a repository.
Committed to repository? I can see already an important question raising:
All those console.* calls are synchronous and take away valuable computing time from running the code that matters. How do we make sure that it doesn’t degrade the performance of our released application?
There’s a simple trick. We configure Babel to remove all console.* calls for release builds. This way we can keep our development environment full of information logged, without impacting the performance of the final application. It’s easy and you need to add some configuration to your .babelrc file.
I „grew up” programmatically in an environment where logging was important. I was working mainly on backend systems and keeping info on what’s going on your server is pretty important. Especially when something goes wrong and you’re trying to figure out why. Then, having a log of what happened just before was priceless. However, working on mobile applications, it’s different.
Most importantly, when something goes wrong, we won’t see the logs anyway. They’d be stored on a client’s machine, out of our reach.
So, we’d only read the logs while developing and then we have more tools at our disposal — we have the context of what we’re doing (because we’re the ones who are interacting with the app), we have tools to track what’s happening in our Redux stores, etc. So, in such a situation using a simple console.log is perfectly adequate.
Finally, if you’re looking for more development tips, you should check out Brain Picks — a video channel where we use screencasts to share actionable tips and techniques that will help you develop better applications faster!
If you liked this post, why don't you subscribe for more content? If you're as old-school as we are, you can just grab the RSS feed of this blog. Or enroll to the course described below!
Alternatively, if audio's more your thing why don't you subscribe to our podcast! We're still figuring out what it's going to be, but already quite a few episodes are waiting for you to check them out.