Quick tips on all you can do with Promises. Because my tips don't lie!

For this post I hope you're familiar with how to create a Promise, how to receive its resolved value and how to catch a rejection. But if you thought that was it, I have some other neat features and tricks to show you.

The I-want-to-do-something-regardless function

So, you're fetching some data, and your view controller has some state to indicate this to your user. But how do you update this state when your fetching is complete, regardless of your Promise being resolved or rejected? While you could update the state in both a .then() and a .catch() function, Promises has yet another link in the chain: the .finally().

Returning from functions

Did you ever wonder what happens if you return from the functions you chain on to your Promise? You actually get a new Promise, resolved with whatever you return (except for .finally()). This means you can actually recover from rejections, or alter your resolved values.

Synchronous promises

You can instantaneously create a resolved or rejected Promise. It's very easy.

Wait, what? Isn't the whole point of Promises to be async? Not necessarily. Recently I needed to create a Promise which would either be synchronous or asynchronous based on my state, and then I would use that value for some more async stuff. Still confused? Hopefully a code example can help with that.

I can Promise you everything

Consider you need to fetch some data, and wait for it all to be fetched, before you do something. Perhaps this is what comes to mind?

This is starting to look like the callback hell we were trying to combat with Promises in the first place. Instead, you can use .all(). Some code will hopefully be sufficient to explain it.

As you can see, .all() takes an array of Promises, and resolves with an array of resolved values. You should note that this is fail-fast, which means .catch() will run immediately when any of the Promises fails.

"It's a race!"

said Rowan Atkinson in the 2001 film Rat Race. Promise.race() isn't too different from that movie, in the sense that whichever Promise comes first will win. However, unlike the characters in the movie, Promises can also reject.

I'm sorry, I'll stop speaking in code, and rather show you with code.. Oh, you know what I mean!

Initially this sort of looks like .all(), but as you can probably tell, this will resolve with just one value. Simply put, .all() will resolve or reject with the value/error as soon as any of the Promises in the array resolves or rejects.

It's Saturday, I want to head out now

Good, because this was all I had for today.

I hope your X-mas looks promising, and that everything will be resolved!

Promises of opportunities

React is Just Components ™️ - but there are tons of ways to make them. Let's dive in!

React celebrated its fifth birthday in 2018. For a front-end framework, that's a pretty long run! Through those 5 years, new features have been added, older ones have been deprecated, and APIs have changed drastically.

This post will introduce you to all the ways to make a component today, and how you should write the ones of tomorrow.

It started as a factory 🏭

When Jordan Walke introduced the world to React back in 2013, components were created with a factory function - React.createClass. You passed in an object containing your render method (and other methods), and the returned value was your component! Here's how it looked:

You would set the initial state by calling the getInitialState method, and you didn't have to bind event handlers to get the correct this value.

This way of creating components was deprecated in React 15, since ES6 classes provided an easier API - but it's still available through the create-react-class NPM package.

Then came classes 🎓

React was released in 2013 - years before the concept of classes was a part of the JavaScript language. When ES2015 finally landed, however, the React team was quick to adopt classes as their favored way of creating components. In January 2015, the 0.13.0 beta release added them!

Class based components (or class components, for short) should look familiar to you:

Since we're now living in the future, we now have class instance field declarations as well, so the same code could now be written like this:

The JavaScript classes made React a lot less magic - but also a tiny bit more verbose. The fancy auto-binding feature was gone, and so was the mixins. There was a lot of angry blog posts about this at the time, but I think this move was pretty nice nonetheless.

Functions Functions Functions 💥

Whether you were using classes or React.createClass to make your components, it was still a pretty verbose procedure. In October 2015, the React team introduced what they called "stateless function components". This approach for creating components were tailored for the very common case when you didn't need state or lifecycle methods.

Here's a stateless version of our sample component, created as a function:

If you want, you can use an arrow function instead:

Note that the click handler and state now needs to live outside of our component.

This is probably the most used way of creating components. Function components are less clunky than their class alternatives, and are powerful enough for most usecases.

And then there were hooks. 🎣

In a few months, React is going to release the concept of Hooks. Markus wrote about this concept in this article, if you haven't heard about it.

The concept of hooks actually has huge implications for how we write our components. How? Well, for starters it basically deprecates class components! Hooks now provide the power previously reserved to classes to function components as well!

Here's our sample components as a stateful function component:

As you can see, we get access to state (we "hook" into that feature of React), and we can get access to lifecycles the same way. This pattern is incredibly powerful, and provides React with a lot of the power of the previously deprecated mixin pattern, without any of the downsides.

If you're interested in learning more about hooks, please refer to the extensive documentation. Its coming in a few months - and I honestly can't wait to use it!

So... Death to classes? 😵

So with the arrival of hooks, you'd might think the ES2015 classes are heading for the same fate as React.createClass? Well, yes and no. The React team has hinted that the class component might be moved to a separate package, but nothing is set in stone yet. In addition, there's a few features that hooks doesn't support yet, and a lot of user feedback to consider before we get ahead of ourselves.

So this is it! The definite guide to component creation. We seem to be looking at a future of function components only, but you'll most definitely be seeing both class components and React.createClass in existing codebases and tutorials.

How to create components

When creating a web application, it is almost impossible to create it without relying on third party dependencies. But how do you know that the dependencies you use are secure?

At the start of developing a new project, you may choose frameworks and other third party dependencies which are popular at the time. If the dependencies are well maintained, they are hopefully free from known vulnerabilities and safe to use. To make sure, you should consult a vulnerability database, like the National Vulnerability Database.

Using dependencies you can trust, is very import to get a solid foundation for your application, but as soon as you deploy the application for the first time, a new vulnerability may already have been found. You can never be sure that all vulnerabilities have been fixed in library, thus you need to periodically scan them.

Scanning in the development process

While you are developing, and building your application, you should have a build step which scans your dependencies. Depending on the language and build system you use, a lot of tools are available.

Some of the tools you can use in your build pipeline are:

OWASP Dependency Check has support for Java, .Net and more.

NPM Audit checks packages in NPM for vulnerabilities by running npm audit.

Retire.Js checks JavaScript libraries in your application, can also be used with a browser plugin.

Brakeman will check your Ruby dependencies, and is created for Ruby on Rails. It will also do static analysis of your code.

Running one or more of these in your pipeline, and possibly failing the build, will stop you from deploying known vulnerabilities.

Continuous dependency scanning

It is normal that an application can live many years after the development process is finished. This means that many of the libraries will get old, and in many cases will have known vulnerabilities after time passes.

To make sure we get a notice of new vulnerabilities, we should do the same scan as we do during the development process every day. If the code is hosted on GitHub, and the code is written in one of the supported languages, continuous dependency scanning is very easy. GitHub will run it automatically on public repositories, and it can be manually enabled for private repositories. Read more about GitHub vulnerability scanning here.

Scanning containers

With docker and other container systems, the system tools and other dependencies inside the containers are our responsibility. They will not get automatically patched as in a normal OS. This is why it is just as important to scan your containers, because the application is just as secure as the least secure component.

If you are using Docker Hub, they have created a scan you can add to your images, and you can read more about it here. Other alternatives are Anchor, and an open source alternative made by CoreOS which is named Clair.

Most of the tools suggested here overlap with each other, and you should test them and see which works for you. The most important lesson from this post, is that you cannot know if your software or its dependencies are secure, and it is your responsibility to make it as secure as possible.

22-Dec

Today's posts

Promises of opportunities

How to create components

Scanning Vulnerable Dependencies