How to rock and roll with Optional Chaining

Elvis Presley Operator

Are you being a responsible developer and rocking your undefined-checks to prevent TypeError like this?

That's nice, but you may have noticed it doesn't roll very well. While it's great to protect yourself from type errors, it can get tedious and cumbersome, and it doesn't feel very DRY.

I hope this won't leave you all shook up. Instead, you should read on - it's now or never!

Rock and roll 🕺

As you learned on Day 1 JavaScript is always open for suggested features and additions. One of these suggestions is called "Optional Chaining", and is about the operator best known as the Elvis operator.

The suggested operator looks like this ?., and you can use it to chain undefined-checks:

This will check if both customer and address is present, and give you the value of street. However, if customer does not have the property address, or if customer.address does not have the property street, your variable will receive the value undefined, and no type errors are thrown.

You can even use this to safely (kinda) run functions or access items in an array:

This will make sure both api and api.getCustomer is present, before trying to run getCustomer. Beware though, that this will still throw a type error if getCustomer is not a function.

Could I go wrong with this?

Yes, there are some limitations and gotchas to this feature.

The biggest pitfall might be that each operator will only check the current link in the chain:

For more details I suggest you have a closer look at The Proposalthe proposal.

Awesome! When can I use it?

Now! While the feature is currently in stage 1, it is of course available as a babel plugin.

I don't know about you, but I just can't help falling in love.

Elvis Operator

I've lost count of the number of times I forgot to bind this. Why do we need to bind this and how should we do it?

Why is this so hard?

To better understand why we need to bind this in React, we should understand how thisworks in JavaScript. Let's take a shot at it with the following snippet.

Awesome! That worked as expected, but will this?

Wait, what!? We got a TypeError saying catchphrase isn't a property of undefined. Why is that?

In JavaScript, this is determined when a function is called, not when the function is defined. Moreover, this refers to the context of the function.

In the above example we create a new variable greet. greet is a top level variable so its context is undefined, and undefined does not have a property named catchphrase. Unlike santa.greet which has santa as its context, due to implicit binding.

To better understand implicit binding, consider this example.

Bazinga! This works because the greet function is called in the context of sheldon, which has a property named catchphrase.

Binding it ourselves

Sometimes we might want to specify the context of a function. This can be achieved with the bind function, and is called explicit binding.

Calling bind on a function returns a copy of the funciton with the argument as the context. In other words this is always whatever argument you pass to bind for that function. This even works if the implicit context is changed.

What about React?

Let's transform our example into a React component.

Clicking the button should ideally print Ho ho ho ho! to the console. However, it does not in the above example.

In the sayCatchphrase function this would be undefined. This is because the event handler function loses its implicitl binding. As mentioned previously, the context is determined when the function is called. When the event occurs and the function is invoked, the context falls back to the default binding and is set to undefined.

To fix this we have a couple of options. We could bind the function ourselves:

It is considered best practice to avoid binding your functions in the render method.

We can use an arrow function. This works because this is bound lexically. This means that it uses the context of the render method as its context.

Or we can use the public class field syntax, which is still experimental and a babel plugin is required to use it.

That's it!

Why is this so hard?

After grabbing your favorite double pumpkin spiced latte with soy milk, you get ready to lean back and browse the latest memes. But should you be connecting to the coffee shop WiFi? How dangerous can it really be?

When smart phones where in their infancy, and the only device people owned that used WiFi was a laptop, an open WiFi was difficult to come by. If you were lucky enough to find one, it might quickly become your go-to location for internet access. These days, open WiFi hotspots are everywhere. They seem like a blessing that might save you from going over your data quota, and provide high speed connectivity. Unfortunately (as with everything) there are some security issues with using public WiFi that you should be aware of.

I see your traffic

When you connect to the same network as someone else, it means that they might be able to see your traffic. Nowadays of course, more and more web traffic uses TLS, making this a lesser concern, but there are still plenty of sites that don't have HTTPS, or defaults to HTTP. Some sites may also handle login over HTTPS, but not secure the session cookies. In 2010, the extension FireSheep made it possible to highjack Facebook HTTP-sessions with a single click, providing you shared a network with the victim.

While this is an issue on any network, the biggest risk emerges when you use a public network that anyone can gain access to. At home or at work, you (hopefully) have some level of trust in the other users, while you have no idea what kind of evil hackers frequent the same coffee shop as you.

This isn't the WiFi you're looking for

One clever way of gaining access to other peoples information is to set up a WiFi that appears to be a legitimate free WiFi (e.g. AIRPORT), and route all the traffic through to the internet. This way, you will think that you have connected to the correct network, while the attacker has the opportunity to execute Man-in-the-middle attacks on you. The only thing an attacker needs for this to be successful is a stronger signal than the legitimate hotspot. They might even emulate the "Terms & Conditions"-page that many coffee shops and airports make you click through to be connected to the web.

What should you do?

Well, that really depends on how paranoid you are, and how sensitive the information you are handling is. For most people, it is enough to be aware of the issue, and act accordingly. Don't log in to your bank, send your social security number, or discuss business secrets on public WiFi. Feel free to browse the news, and post some memes. You should however think about the fact that many services run in the background on your device. If you have your company email set up on your phone, you might have to think again before using the coffee shop WiFi. One solution that will allow you to still use unsecured WiFi is to connect to the internet through VPN. With a VPN connection, all your traffic is encrypted between your device and the VPN server. This makes it impossible to listen in, even on the HTTP-traffic.

Of course, if you use a commercial VPN provider, you have now placed your trust in their security and integrity, but that is a story for another day. Many people have access to VPN through their workplace. If your work VPN allows you to route all traffic through the VPN, this will be a good option to increase your security.

Finally, if you have to handle sensitive information while away from home and the office, using mobile data is probably one of the better options. As long as you are able to trust your cellular provider, 4G data network encryption should provide you with the security you need.

3-Dec

Today's posts

Elvis Operator

Why is this so hard?

Public Wifi