Do you avoid testing of components that depend on Redux because you fear the complexity? Are you loosing sleep worrying about configuring huge mock stores for testing the simplest of components? Fear no moarrr!

The easiest solution will in some cases be to configure the original Redux store with your favorite root reducer as you would in real life production code. It's actually not that complicated!

The component under testing

Let's say you've made a React component that renders a Christmas wish list. The wishes comes from the Redux store:

Wishes can be added to the list by dispatching an action with type ADD_WISH and data like Buy sexy Santa outfit. If working as intended, the component should update the wish list when this action is dispatched.

Testing the component with a real Redux store

Let us make testing of the component as close to reality as we possibly can. How? By skipping the creation of a mock store and making a real one. The following snippet shows how to set up the store together with the component, just like in production code:

So, to test that the component behaves correctly:

Awesome? We think so!

Testing of React component with a real Redux store

Make an effort on User Experience and security awareness when implementing "Forgot password", and avoid exposing sensitive user information

We've all used the "Forgot password"-feature somewhere on the internet. Some were positive and quick with great user experience (UX), while others were... well, not so much. Maybe you received your password back in plain text, maybe the procedure required you to remember your first pet's name or the street you grew up in. Implementing an insecure "Forgot password"-feature might lead to the security vulnerability Sensitive Data Exposure which will harm you and your users.

So let's look at a few suggestions on how make a great and secure "Forgot password"-feature!

The user forgets, and so should you

When a user forgets their password, they want you to help them with logging in. They don't want you to help them to remember what it was in the first place.

Present the user with a "Reset password"-feature that resets their password. Clicking on that link can send them an e-mail/SMS with a unique & time-limited link to a page where a new password can be typed in.

Don't everretrieve or recover the user's password! By retrieving or recovering their original password, the user knows you know their password! Not good!

Your Ashley Madison affair was never a secret

This is a great example of abusing a well-intended feature in order to get potentially sensitive information about a victim,e.g. if a person has an account with Ashley Madison or not.

Ashley Madison was hacked as well (and account information was leaked), but our example here is a security vulnerability that was already in place.

How you tell if they were having an affair?

When an "attacker" wanted to know if your e-mail address was in use, the attacker could present the user's e-mail to the "Forgot password"-form. If the website didn't find an account by that e-mail, an error message was shown. If the user had an account on the other hand, the website sent the attacker to a receipt page with further instructions...

So by observing the two "Forgot password" behavior patterns, the attacker could infer that the presence of an error message meant that you didn't have an account, and getting to the receipt page meant that you did.

Troy Hunt, who revealed this flaw in a blog post, states that the lesson for the end-user is:

always assume the presence of your account is discoverable

Which is sound advice for any web citizen.

While the lesson for any website owner is that the website shouldn't respond differently based on user input for these kinds of sensitive security features.

Don't use company branded e-mail templates

Heavy use of HTML-templates with images, logos, formatted text etc. will increase the risk of the "Forgot password" e-mail (or any e-mail for that matter) landing in the user's spam folder, or being blocked by the e-mail server's spam filters.

Since this is such a critical e-mail which the user must receive, cut and minimize content down to just plain text with a simple link to reset the password.

Anything more is distracting and not helping the users in their frustrated state.

Outsource your Identity Management

Security and identity management is hard. By not outsourcing it you need to be making sizeable investments in security and UX in order to:

have a competitive advantage

have a great Customer Experience (CX)

provide a safe service for your end-users.

By avoiding rolling your own Identity management and instead using a cloud provider, such as Google, Amazon, Azure or Auth0, you can trust the experts of their fields to do the right things for you and your users.

Some vendors, like Auth0, have invested a lot of resources into making these features as friction-free as possible for your end-users. Their "Password Reset" feature is excellent and well thought-out, and proves that they understand how important such features are to CX.

If you do roll your own Identity management, make sure to understand the security and UX-design decisions behind examples such as these.

I'll leave you with a quote from Auth0:

Password Reset Is Critical For A Good Customer Experience

Forgot password - your chance to shine, or fail

In the first post of this calendar we learned about TC39 and how JavaScript is evolving. It has not always been like this. When the TC39 committee was working on the last huge update (ES6/ ECMAScript2015) to the javascript specification they decided that the process for updating it should be improved. This resulted in the current TC39 process. After the new process was adopted, updates to the language became smaller, incremental and released annually.

This Monday (the 3rd) we had a look at the elvis operator which is currently working its way through the TC39 process. Today we’ll have a look at some proposals that already made it to the fourth stage and has become a part of the language.

The 2016 update

2016 was the year everything happened. Brexit, the election of Trump, the death of David Bowie, the signing of the Paris Agreement, and the first annual update of the ECMA specification. In an effort to avoid overloading the world with change in one year, this update was kept small and only two new features were added to language.

Array.prototype.includes

This is a handy little function that lets you determine if an array includes an element.

This is cleaner than using the indexOf function, which is how it was done in the good old days.

Exponent operator

Yep, javascript didn't have an exponent operator until the 2016 version of the spec. Now it has!

The 2017 update

The 2017 update is bigger than the first one. It includes the functions covered below as well as some larger additions, like the async and await keywords. These are important enough to get its own day in someones javascript christmas calendar.

Object.values and Object.entries

These two functions were added in 2017 to complement the existing Object.keys function. Object.keys returns an array containing all keys of an object’s properties. Object.values returns all values of an object’s properties.

Object.entries returns an array with all entries of an object. An entry consist of the key and value of a property put together in an array.

One useful application of this function is that it makes it easy to create maps from objects.

String padding

You might remember left-pad gate. This was that time in March 2016 when a few packages were unpublished from npm and all of a sudden nobody was able to build their code. The package which caused all the troubles is called left-pad and was soon republished to npm to fix the mess its removal created.

Just months before left-pad gate, the TC39 committee was discussing when to advance a proposal containing two additions to the String prototype, doing the exact same thing as the left-pad package is doing. String.prototype.padStart lets you pad strings to the beginning of a string (the left-pad equivalent) and String.prototype.padEnd, which let you pad the string at the end of a string. This proposal was later moved to stage four and was included in the 2017 update.

The 2018 Update

The number of proposals which made it into stage 4 in 2018, was even larger than in 2017. We saw some updates to regular expressions, an addition to the Promise prototype and asyncronous iteration.

Rest / spread object properties

In the 2018 update the rest and spread operator ... for object properties were also added to the language. The spread property for objects is useful for making shallow copies of objects. In the example below we create a fakeSanta object with the same properties as santa. Then we override the hasRaindeers property and add one extra property.

A thing to watch out for is if ...santa is at the after hasRaindeers: false, then fakeSanta.hasRaindeers will end up being true as it is the last thing that is assigned to a property that counts.

The rest property is useful when using the destructuring pattern if there's an unknown number of properties in the object being destructured. With the object rest property we can do the following:

Wrapping it up 🎁

We've now seen a few of the additions that have made it into language since the new process got adopted. Make sure to check out the full list of additions here.

5-Dec

Today's posts

Testing of React component with a real Redux store

Forgot password - your chance to shine, or fail

The proposals that made it