There are books with entire chapters dedicated to this topic, but this article will give you the crash course you might actually remember.

There's some things about how JavaScript works that you simply need to know as a web developer. I would say the inner workings of what we call function context and the this operator definitely is one of them.

There's a plethora of explanation attempts to be found, some great, some less great, but this one has mainly one goal: to be short and to the point.

Bring on the short and pointy

All functions are being called in what we call a context, which is basically just what the value of this is inside the function. Whenever I talk about function context (scary tech term), I'm basically talking about the value of this (what you want to learn).

This article consists of five parts: one main, baseline rule for what this points to and four exceptions to that rule. With these five, we'll be able to always deduce what this will be!

The baseline rule

Method calls

Constructor functions

Arrow functions

Setting context explicitly

The Baseline Rule

This serves as a rule of thumb, always to apply unless one of the exceptions is present.

The value of this is always the global browser object window.

This is rarely useful, and is the root of oh so many bugs.

Even if you at some point have the context point to something other than window, once you create a new function, you're back to window:

Exception 1: Method Calls

When calling a function that lives on a JavaScript object, we call that function a method. Calling such a method is a method call.

Whenver calling a method, the value of this within the method being called will be set to the object on which the method exists.

This is why Java- or OO-like patterns will work in JavaScript as long as you call functions intended to be used as methods directly on the object.

Simply put – if there's a . in your function call expression, the function context will be whatever is in front of the ..

Saving a reference to a method and calling it without the . won't retain the context.

Exception 2: Constructor Functions

In the previous section, we used the new operator to create a Person object. How does that work? 🤔

Here's the thing: there's nothing special with our Person function. It's not a special constructor function – it's just a function like any other. It becomes a constructor function only when we call it with new.

Here's what happens when you call a function with new:

A new, empty object is created

The function context will point to that object

That object will be returned from the function, no matter what (and if) you return from the function

Therefore, it's evident that the value of this changes by using the new operator.

Exception 3: Arrow Functions

Arrow functions are quite simple in this regard. They just.. don't have their own context. They inherit whatever the value of this was in their parent scope.

This is quite often a desireable property of arrow functions, relieving you the issue of ensuring the context is right inside your function.

Exception 4: Setting context explicitly

Of course, JavaScript provides a way for us to set the context ourselves.

Instead of calling a function normally, we can use the call function that every function has:

The first argument to call will be the function context, while all other arguments are passed to the function being called.

While call will call the function immediately with your specified context, we could also create a copy of a function that we can call later using bind:

These context-binding functions are used extensively in JavaScript, especially in various frameworks to guarantee that important functions that get passed around are called with the correct contexts.

That's it!

More thorough explanations are a dime a dozen on web development sites. But, just' by remembering just these five simple rules, you'll be able to understand how it works without needing a thick JavaScript book by your side at all times.

Happy coding!

Five simple steps to understanding *this* in JavaScript

Containers is the currently best way to build software for platform independence, and an orchestration service manages them, but how about that security?

Containers

In the same way as a shipping container is a standardized unit for transporting goods from one location to another. Software has adapted the same way of thinking. Package software into a standardized unit for simplifying development, shipping and deployment. This leaves a smaller footprint on the servers that run the applications, but also allows higher server density.

One argument is often that containers are more secure than the alternatives. One of the reasons is that the attack surface is smaller, and allows for hardening of the host. It's less complex to protect an application and its dependencies within a self-contained unit.

Attacks

There are still pitfalls! Malicious container images are still a problem today, this is identical to the problem Google faces with malicious applications in Google Play. Another problem is container escapement. This one is scary as it allows for lateral movement, or compromise of a an entire cluster.

Orchestration services

Orchestration is a way to organize containers for automation. This allows fast scaling and cluster management in order to coordinate running containers across multiple nodes (computers) in a cluster. Docker Swarm and Kubernetes are both open-source, and without a doubt the most used orchestrators today, and have moved from the SOA way of doing it to the more modern microservice. What? I still don't get it.. Ok, we can compare an orchestration service to the actual orchestration of music. Where the developer is the composer, the worker nodes are the musicians, the manager node is the conductor.

Attacks

Keeping with the music theme: There are many ways and motives for an adversary to interrupt the sweet music played by the orchestra. An attacker could throw rotten tomatoes. He could sit in the audience with a tape recorder and sell the bootleg recording after the show. Or he could be more Machiavellian and infiltrate the orchestra to play the wrong notes on his instrument with intent. The other musicians would abruptly kick him out after this, but if the attacker can impersonate as the conductor, he could wreak havoc in the orchestra, and the musicians would not dare to question his leadership.

The trust given to an orchestration service makes it a target for attackers, as a large portion of applications running in the cloud are containers. See the problem?

The way to protect your orchestration service is to employ strong cryptographic identity for all nodes, and this can be used for providing mutual transport layer security. Fine grained access control can reduce your attack surface. As we saw last week Kubernetes did not have this in place as the bug allows for bypassing the authorization logic. Enable encrypted traffic between nodes, even though it will cost you a small amount in terms of computation. Remember that we have traded code-complexity for network-complexity, and that the side effect of this is that data on the wire can be read and modified if it is unencrypted.

Final notes

Should you use containers? Yes! Should you trust your orchestrator? Propably.. Should you take action to harden the host you run your containers on? Definitely

Photo credit: Containers by Glyn Lowe, under CC 2.0

Security in containers and orchestrations

A festive introduction to Hooks, and what you can do with them!

From time to time, you create a React component as a function since state is not necessary at that point. In the end, you catch yourself converting your function into an ES6 class anyway. Unfortunately, classes often tend to become complex and make code reuse difficult. Thanks to a new feature proposal called Hooks this may become a matter of the past sooner than you think!

At the time of writing, React Hooks are only available in React 16.7 alpha. They aren't introducing any breaking changes and can easily be used side by side with stateful logic that you have implemented at other places in your application (you just can't use Hooks in ES6 classes). The feature proposal introduces several different types of Hooks (you can even build your own Hooks). This article focuses on two of those: State Hooks and Effect Hooks.

State Hook

Before Hooks were introduced, an app that would help Santa keep track of how many gifts he delivered would probably have looked like this:

We have an initial state { giftCount: 0 } which can be changed by Santa pressing a button that calls this.setState(). When we want to display the gift count, we use this.state.giftCount.

Using a State Hook, the result becomes a lot more compact:

First, we have to import the useState Hook. Then, the initial number of gifts (which is zero) is passed to the Hook as a parameter. useState returns an array containing the current state (which we called giftCount in this example) and a function (setGiftCount) which triggers a re-render of the component and updates the state. In addition to numbers, State Hooks work fine with strings, booleans or objects as well. You can even define multiple Hooks in a single component:

Why 'this' isn't so hard anymore

If you've read the third article of this Advent calendar, you may recall that binding this can be troublesome and that you probably have forgotten it several times. Since there is no this in function components (functions don't have instances), we don't need to worry about it when using Hooks. Isn't that awesome?!

Effect Hook

While State Hooks let you use stateful logic in function components, the Effect Hook makes it possible to perform side effects (such as fetching data from a server, changing the DOM, etc.). By default it runs after every render (both after the first render and after every update) and can therefore be used to replace the lifecycle methods componendDidMount and componentDidUpdate.

We can now extend our app to fetch the next gift to be delivered on every re-render (e.g. when giftCount changes):

As you can see, we imported useEffect and added the Hook to our component which fetches information about the next gift and stores the value using a newly added State Hook.

Skipping Effects

Sometimes you don't want to trigger your Effect Hook on every re-render. This can be achieved by passing an array as a second argument to useEffect. Passing an empty array will only run the effect when your component is mounted and unmounted. If you pass an array containing some values, the effect is skipped as long as these values aren't changing.

How to continue from here?

Hooks are experimental and their implementation might change in the future. Therefore, you should wait to use them in any critical projects. Until then, you can try Hooks here, or start using them in your hobby project. Hope you got hooked on Hooks!

17-Dec

Today's posts

Five simple steps to understanding this in JavaScript

Security in containers and orchestrations

Ho Ho Hooks