How to use Reactrotron to really improve your React and React Native development

I've primarily been a React or React Native developer for the past three years. During that time you get to experience quite a few things. One of those things is the love/hate relationship with logging and debugging. For me that was especially true while developing for React Native, where errors would apparently origin in the most peculiar and hard-to-figure-out places.

Then, a couple of weeks ago, I learned about Reactotron and thought it looked kinda neat. It's a stand-alone app that connects to your app and greatly improves logging and debugging. Sounds interesting? Let's have a quick look.

Setup and basic usage

After you've followed the guide in the Reactotron repo, installed the app and then --save-dev-ed the package in your project, we are ready to setup Reactotron - which is a breeze. All you need to do is add this piece of code, preferably in your root component:

With that and a refresh, your Reactotron interface should show a connection. There's not much there just yet though. Let's fix that.

Say if we are requesting data, Reactotron will now know about this and present it way better than console.log-ing the data would. And also you don't need to log it manually at all, which is pretty nice.

Errors

We all write code that doesn't run. It happens. As I mentioned in the beginning I've found that especially React Native sometimes isn't the best at saying what went wrong and where it might have happened.

If I have this:

I've apparently forgotten to bind the function called in componentDidMount to this, resulting in an error. Instead of looking at the dreaded red screen of death you can turn to Reactotron once more, and see this. With a bonus comparison:

Here you might see in the read screen where the error is located. But I've found Reactotron to be way nicer to work with than this.

Benchmarking

There is also built-in functionality to benchmark your app. You might have slipped on the keyboard and written a function that really affects the rendering. But what is it that makes it so slow?

For the sake of the example, I'm going to use the previous function for getting data from the API, even though this might not be the most common benchmarking use case:

If we want to benchmark this function we can expand the code to this:

Reactotron will then show us something like this:

Is that it?

Not at all. Reactotron has plenty of more functionality. You can track all network requests, async storage, state changes and more. You can connect your Redux or your MobX.

If you feel that something is missing and feel like contributing you can even write your own plugins!

Have a go at it and see if it's something that might improve your workflow.

Supercharge your logging and debugging

Meet the beautiful first class citizen of JavaScript. The function. And all it's declarations.

The function

One can write books about the JavaScript function. I'm sure that people have, too.

But let's rather make this really short. In opposition to other popular languages, like Java, functions in JavaScript are considered first class citizens of the language. This means that you can pass them around as arguments, make functions that in turn return new functions, and essentially use them as any other value in the language. For instance, functions may be a property on JavaScript objects (then named methods).

The fact that functions really are first class citizens in JavaScript, also make the language highly flexible. For example, you can create closures with functions in JavaScript:

The 7 ways of the function

One of the things that new JavaScripters find confusing after a while is the function declaration. At MDN we find the definition of a JavaScript function to be defined as:

A JavaScript function is defined with the function keyword, followed by a name, followed by parentheses ().

But after a while of being acquainted with JavaScript, the statement holds only so far. I present to you, the 7 different ways of declaring a JavaScript function in 2018.

The function declaration/definition/statement

The first we learn, I guess. Nothing fancy here. Looks similar to other languages.

The function expression

Beware. If you try to reference a function expression before calling it, your code will fail:

The arrow function expression

After ES2015 (named ES6 back in the days), we also got the handy and quite petite arrow function expression. This syntax works especially well when chaining the built-in map/filter/reduce. Kinda like below:

However, beware the following before you consider using arrow functions:

You do not have the special arguments object inside the function body.

You cannot say new (() => {}).

They do not have their own this, arguments, super, or new.target.

The function constructor

Well. This is awkward. This one is not the simplest nor intuitive. And guess what, it's not recommended by MDN. However, if you know of a usage, we would love to hear about it!

The function body is created as a String?! Fun with functions, man. It never ends 🤓

The others...

...are called (pun intended):

The generator function expression.

The generator function declaration.

The GeneratorFunction constructor.

Generator functions will not be subject to this post. More about this here.

IIFE's and the anonymous function

Functions are pretty cool. And as everything that's cool, they can also be anonymous. In JavaScript, we also allow for unnamed functions. Did you know that you also can invoke them immediately? Say hello to the Immediately Invoked Function Expression (IIFE):

Fun(ctions)

At the beginning, web pages were very static. They were written in HTML, and the web browser had one job, to render the HTML to a page filled with text, images and links. After a few years, the developers wanted more, and JavaScript got introduced.Together with JavaScript came a new breed of vulnerabilities, where the attackers could exploit the possibility to run code in browsers, this was called Cross Site Scripting or XSS.

JavaScript has a lot of possibilities, and a lot of responsibility in modern web applications. First of all, JavaScript can see and read (almost) everything that is sent to the browser, e.g. all the countermeasures we wrote about CSRF some days ago, are no longer valid. This is because JavaScript can read everything, even if it is hidden on the page, send and read as the user.

In addition, JavaScript can read secrets hidden under the domain, like the session cookie. There are countermeasures against it, because JavaScript does not need to explicitly set the cookie on the requests, this is done by the browser automatically. By setting the flag HttpOnly, a cookie can never be read by JavaScript, only sent as a header on http requests. But it is a nice example of what we can do, so let us use it.

An XSS can happen in many circumstances, but the main reason is that a user can inject unescaped HTML in a website.This is similar to what we discussed in the post about Injections, and in HTML (or XML), the <, > and " are very important for the markup, there are more, but let us start with those. An escaped version of < is &lt; and > is &gt; and " is &quot;, short for "less than, "greater than" and quote if you want to remember those.

Reflected XSS

If we imagine we are Google. We have a search input field named q, where the query is inserted, and the query is put as a get parameter in the url. If we insert santa, and click search, the url will be https://www.google.com?q=santa. And the input field will render like <input type="text" name="q" value="santa" />. If the rendering of the value in the input field is not escaped. An attack could be to insert

This will render the input field like

As we see, " /> closes the input field and let the attacker continue to write HTML. Which in this case let santa steal all the cookies from the users who click on the link with the malicious input.

This is called "Reflected XSS", because the input from the user is reflected on the website But this does also limit the reach of such an attack, because the user often needs to click on something before it works.

Stored XSS

We also have the "Stored XSS", which is quite similar to "reflected XSS", but here the malicious input is stored on the server, and could possibly affect all users. If Santa creates a blog where he writes about his Christmas preparations, he would likely create a comment section for input from his fans. The comments are printed out in the bottom of each blog post, but Santa forgot to escape the comments on the web server. If the Grinch finds this, and creates a comment with the input:

All the readers of that blog post are met by a popup with the text "Santa does not" exist.

As we see in this last example, the XSS does not need to happen in an attribute. It can happen all places where text is rendered. That is why the web server should always escape everything, except those places you actually write HTML-code.

DOM based XSS

The last type of XSS is "DOM based XSS". The main difference between this and the other two, is that it all happens in JavaScript. JavaScript has methods like innerHTML, which can be used to fill another element with text, but it does also allow HTML to be written.

As a simple example, we have a div with the id website, where we want to display the url of the current website. Code to fill this could look like:

An example of a malicious url would be https://www.santaisbad.com/#<script>alert("Santa is good");</script>. And we will get the well-known alert box. But the most important is that the developer does not even know that the website is being exploited. The web browser does not send the #, and everything after it to the server, which makes it difficult discover.

In addition to escaping what we render, to get rid of "DOM based XSS", we need to go through the code and use the correct methods (or even delete vulnerable code where this can happen, like eval). Instead of using innerHTML, we should have used innerText and so on.

As a final reminder, escape everything, and take care when rendering mixes of text and HTML.

In many frameworks, both server and client side, it is the default behaviour to escape output, but you need to check this to be sure.

13-Dec

Today's posts

Supercharge your logging and debugging

Fun(ctions)

Cross Site Scripting (XSS)

Sign up for our newsletter

Join in the holiday cheer and count down to Christmas with us!