Chrome’s security policy will only allow you to access your device’s microphone/camera when a site’s has a secure origin. See here for a detailed explanation about what a secure (and unsecure) origin is. In summary; you need to host your site on https or called localhost (for when in development).

This can cause problems if you’re using a dev environment like Vagrant. You could have many named local websites configured. Moving them all over to localhost could be a real pain; both impractical and time consuming.

To ignore Chrome’s secure origin policy, follow these steps.

1. Navigate to `chrome://flags/#unsafely-treat-insecure-origin-as-secure` in Chrome.
2. Find and enable the `Insecure origins treated as secure` section (see below). …

Double clicks can be a real pain point in UI development. Clicking buttons too many times (or before an action has had time to finish) can have a variety of buggy consequences. Yes, users could be more patience; but chances are they’re hammering the button because your system is laggy to begin with.

I’ve found buttons triggering HTTP requests to be a particular problem. When a user has NO visual feedback an action is taking place; how are they meant to know to wait?

Its easy for developers to overlook this problem. We’re more interested in the final result of a function call; not the immediate consequences of initiating it. …

(I have since written a revision for this post for a newer version of UI-Router. The concepts are the same; just updated to reflect some minor changes in how UI-Router should be implemented. This can be found here.)

React has a key advantage over other frameworks. It’s very selective about what ships with the core. This means developers are able to find and install packages that best suit their project. Resulting in a leaner framework and making it very extendable.

Routing is a major element when building single page web apps. React doesn't have the capability to it out of the box. No built in routing library ships with the framework, you have to install your own. …

When starting a new React project its easy to imagine not using anything from the window object; it feels old-timey and makes your code looks terrible. The thing is though, so many SDKs and third party libraries still (and will always) utilise it. It’s very convenient way of setting and accessing global variables after all.

The compromise I’ve found that works really well is to alias it as a service. A file that lives in the project structure where the variable is declared and exported. …

Promises are a common part of JavaScript development these days. One of the things I find a bit frustrating is detecting whether something is a Promise or another type of built in object .

When using a promise it will usually have a callback and a catch chained on the end. It’s important to check variables for suitability; otherwise it will throw an error and probably take out your app in the process.

const foo = new Promise(() => {});
const bar = ‘Promise’;// The wrong solution
console.log(foo.then && typeof foo.then === 'function'); // true
console.log(bar.then && typeof bar.then …

When testing React components you want to be very specific about what’s being tested, keeping everything lightweight. Loads of configuration in a test is usually a sign something is not right with your approach to the test (or the component).

You should always be looking to use shallow rendering. This is a real unit test, provides an element of isolation and child elements aren't rendered. Helpful methods like instance can be called giving access to properties on the component allowing you to interact directly.

For most low level components shallow rendering is easy to setup and use. Redux components can be more troublesome. If your component is wrapped in the <Provider> service you can’t take advantage of shallow rendering due to it being applied to that instead. …

Over the past year at Gecko we’ve added several new members to the team. As a result, one thing in particular became apparent. Our approach to planning was not sustainable. (This is a story for another time.)

An obvious area of concern for us was where the work was spec’d; the JIRA tickets. While product (and sprint) planning is not just about logging tickets, it does form a fundamental part of it. The aim of this post is to outline a structure for how we construct user stories and bug tickets.

To recap our situation. Tickets would be poorly worded and lack suitable descriptions. They often failed to CLEARLY describe a problem or highlight the specific area of focus. This was the major issue. How are you meant to fix something if you can’t replicate it or even understand what the problem is? Adding new members to the team only made the situation worse due them still learning the product and lacking first hand knowledge of previous and existing issues. …

Using components within other components is one of the most common things you will do working with React. What happens when you need a more elegant solution for conditionally rendering these though?

If and switch statements can do the job fine for a predefined list of components, but what if you want to set it directly based on a prop passed into the parent component?

Your initial idea may be to do something similar to what is shown below. Attempting to set the tag name (directly) via a general expression. This wont work and will cause a compiler error.

render() {
    return <[this.props.tag] />…