In the majority of codebases you will see statements as below:

if (this.age) {
  this.postUpdate(age);
}

And why not. They look good and even encourage sexy one-liners:

if (!this.age) return;

These checks are fruitful soil for bugs of any kind. Read why.

Let’s start with some basics

To understand why above statements are usually not the way to go, we need to understand the results of below expressions.

I assume that in most of your use cases you actually want to check a variable against null and undefined values and not against an empty string or the number 0.

if (!this.variable) {
  // matches: "", 0, undefined, null
}

if (this.variable == null) {
  // matches undefined, null
}

I get it,

if (variable == null)

does not look that sexy — but trust me, once you start applying it as your default way, there is no way back.

I gathered some examples which cause unexpected behaviour or are simply bugs.

Example 1

This function returns the function result of the trueFn invocation if an expression is defined.

Problem

Passing in an empty string “” or 0 number will result in a falseFn invokation. You may imagine, that passing in 0 or “” can be a very common use case in this scenario.

Fails

// age=0 should be a valid option
when(age, () => 'Her age is:', () => 'Loading');

// if bio is an empty string, then the input should be empty as well
when(bio, () => bio, () => 'Loading');

Solution

Example 2

This is an event listener callback gets called whenever the value of an input changes. The intention of the developer was not to exclude 0 and empty values.

Fails

// Both were allowed values

_valueChanged(0)
_valueChanged("")

Solution

Example n

Every other month I find bugs related to the usual way of checking variables. I’ll keep adding them if time allows.

In a rising number of popular JavaScript libraries, you’ll see the double equal null checks in their codebase. Underscore, Less and even JQuery apply this principle. Linters allow the use of loose equality checks when it comes to null. See also AirBnB’s best practices https://github.com/airbnb/javascript/blob/57ff032b0740ba2a46af4bc40cf5638a3e62a365/packages/eslint-config-airbnb-base/rules/best-practices.js#L40

Strict type checking might be another option to do those checks. However, I believe that in at least 80% of the the times we write this code unconciously and do not think of all possible scenarios. If your default way of checking against defined values is ==null, then you should be fine in most cases.

See also http://adripofjavascript.com/blog/drips/equals-equals-null-in-javascript.html

The actual heading should be: A short story about the weird parts of NaN

NaN in JavaScript stands for “Not a Number”. The type of NaN is surprisingly Number. Which is weird because it is used to define something which isn’t a number.

typeOf(NaN); // "number"

It is used for instance for a result of a bad calculation.

var a = 3 * "jalal"; // NaN

The most confusing part aboutNaN is that NaN compared to anything else is always false!

NaN == false; // false

NaN == true; // false

An even compared to itself equals always false.

NaN == NaN; // false

NaN === NaN; // false

This raises one question:

How to check if a variable is NaN?

There is a function in JavaScript called isNaN(), but it has, unfortunately, some issues on its own.

Let’s go through some examples:

isNaN(NaN); // true

That worked!

isNaN(1); // false because 1 is a number

This is also not surprising!

isNaN('1'); // false

This worked too because isNaN coerces the passed in parameter and then checks if it is not a number.

isNaN('a'); // true because 'a' is not a number

Again, an implicit coercion is happening here. isNaN tries to convert the parameter into a number. The result of this effort having ‘a’ as a parameter is NaN:

Number('a'); // NaN

parseInt('a'); // NaN

Number('1'); // 1

This is why isNaN('a') returns true. It’s similar to isNaN(Number('a')) .

So basically the isNaN function is useless unless you are 100% certain that the passed in parameter is supposed to be a number.

Again, how to check if a variable is NaN?

We mentioned before that NaN is the only JavaScript variable that returns false if it is compared to itself. We can make use of that!

var a = 3 * 'jalal'; // a = NaN

if (a !== a) console.log('A is NaN'); // a !== a equals to true

This is the only way (I am aware of) to certainly check if a variable is NaN.

You can imagine that those weird parts are important to know because they are fruitful soil for bugs of any kind.

Jalal Fathi is freelance software developer and startup founder. Passionate about web technologies and in love with JavaScript. Learn more.

The Problem.

You finished developing your web app, on-boarded the first people and you are now focusing on growing your user base a bit. That’s the moment you realise, holy shi…, how can I create dynamic OG-Tags so Facebook and other Platforms show different content when sharing different URLs of your page. You research a bit and you figure out that this is not possible with statically hosted websites because Javascript does not get executed by these crawlers.

You stumble upon prerender.io. You think, really, do I have to do this? You start playing around with your NGINX config files and figure out how to proxy requests from social bots to prerender.io. You kind of hate it.

Your next app is hosted on Firebase. You (again) do not think about the importance of dynamic Open Graph Meta Tags. You onboard the first users and start focusing on growth. You remember prerender.io. You think about server config files. You start scratching your head. You think f***. I cannot configure my Firebase server. You start crying. Crying is good for you. You gotta feel it to heal it.

The Solution.

The solution comes with using Firebase Functions, and it’s quite simple.
Just need to add a http trigger, analyse the request, replace your meta tags and return the modified index file. Thats about it.

exports.host = functions.https.onRequest((req, res) => {
  // do your stuff and return the index.html file
});

Let’s take a look at an actual implementation.

1. Add placeholder for dynamic meta tags

index.html

Let’s add some placeholder and replace them afterward with dynamic meta tags in the Firebase function.

<!doctype html>
<html lang="en">
  <head>

    <!-- 
    Gets replaced by URL specific meta tags via Firebase Functions
    -->
    <meta name="functions-insert-dynamic-meta">
    <meta name="functions-insert-dynamic-og">

    <link rel="import" href="src/my-app.html">
  </head>

  <body>
    <my-app></my-app>
  </body>
</html>

We can now reference these functions-insert-dynamic-xyz meta tags in our Firebase function. But the main reason for me to use a placeholder and not just reference </head>, is that they remind me that there is something happening with this file before it gets served.

2. Copy index.html into our functions folder

build/index.html copy tofunctions/hosting/index.html

We need to be able to reference the index.html in our functions. For that, we create a functions/hosting folder and paste the index file in there.
I do that automated while building my app. You may include the build step in yourgulpfile.js or whatever you are using to build the app. I just add below copy action into my package.json file so I can run npm run build.

"scripts": {
    "build": "polymer build && cp build/es5-bundled/index.html functions/hosting/",

},

2. Add the function

functions/index.js

In this example, we want different meta tags with each organisation.

example.com/ => Default meta tags
example.com/xyz/ => Default meta tags

example.com/organisation/red-cross => Check database for the red cross organisation and return specific meta tags

We also only want to make the effort to replace the meta tags if the user agent requesting the page is a bot. Otherwise, we don’t care much and just return the original index file with some default meta tags.

3. Add rewrites

firebase.json

Now we need to make sure, that on every request our host function gets called. For that, we need to add a rewrite entry to our firebase.json file.

"hosting": {
  "rewrites": [{
    "source": "/**",
    "function": "host"
  }]
},

That’s it. Deploy the app and enjoy the magic.

Thanks for reading.

Jalal Fathi is freelance software developer and startup founder. Passionate about web technologies and in love with Polymer. Learn more about how he can help you to create your next digital product. He works wherever he wants and tries to catch a good swell wherever he can. He wrote this bio by himself while writing in third person.

Step-3 shows how to extend our app in order to call a Firebase (or any other) API endpoint. If you are not familiar with using Redux in a Polymer app, go back to Step-1!

// If you want to clone this tutorial:

git clone https://github.com/JaySunSyn/ReduxTodo.git

and make sure to uncomment the step-3 import in index.html

<!-- <link rel="import" href="/step-1/my-app.html"> -->
<!-- <link rel="import" href="/step-2/my-app.html"> -->
<link rel="import" href="/step-3/my-app.html">

Let’s create one more file to include our middleware logic. Our file structure looks now like this:

Install dependencies

npm install — save redux-thunk

Redux Thunk

Redux Thunk middleware allows you to write action creators that return a function instead of an action. The thunk can be used to delay the dispatch of an action or to dispatch only if a certain condition is met. The inner function receives the store methods dispatch and getState as parameters.

What problem do we try to solve with Redux Thunk?

We cannot use async functions in our reducers simply because of the way they work. As we already know, a reducer does not modify the current state. It takes the previous state and returns the next state. So waiting for a promise to resolve would not work here …

Could we solve that differently?

Yes, we can! But we shouldn’t!
In our actions, we could trigger an API call and just return the previous state. After we receive the response, we could dispatch an action which would update the state based on the response.

// DON'T DO THIS

(state, action) => {
    if (action.type === 'CALL_API') {
        callApi().then(result => {
            store.dispatch({type: 'UPDATE_STATE', data: result});
        })
    }

    // implement 'UPDATE_STATE'

    return state;

}

The action is not pure anymore and can have side effects. I think Redux wouldn’t even allow it. See source code here.

What’s a middleware?

In short, a middleware runs in the Store after we call this.dispatch() and before the dispatched action reaches the reducer. (Read the docs for a more in-depth explanation.)

This allows us to hijack the dispatch, call an api endpoint, wait for the response, and dispatch the action afterward with the data of the response!

Implementation

redux-middleware.html

Let’s take a look at our code.

Every time we call dispatch() in our app, callAPIMIddleware gets called. Mostly, we just pass the action on to the reducer and do nothing here. We check if the action has a ‘types’ attribute and if not, we pass it on. If it has a ‘types’ attribute, we assume that we do want to call an API.

Let’s take a look at how our add (or addTodo) action has changed to understand a bit what we are doing here …

const addTodo = (todo) => {
    const params = {
        method: ‘POST’,
        body: JSON.stringify({text: todo}),
    };

    return {
       // Types of actions to emit before and after
       types: [‘ADD_TODOS_REQUEST’, ‘ADD_TODOS_SUCCESS’, ‘ADD_TODOS_FAILURE’],

      // Perform the fetching:
      callAPI: () => fetch('https://example.com/api/todos', params)
    };
};

We return an Object with 3 types.

ADD_TODO_REQUEST: We dispatch that one before we call the API.

ADD_TODO_SUCCESS: When the API call was successful we dispatch that type and add the response as a JSON Object to the action.

ADD_TODO_FAILURE: You guessed it, if something goes wrong.

Our reducers are pretty much straight forward. When adding a Todo, we do not need to do much further and just return the previous State.

case 'ADD_TODOS_SUCCESS':
    console.log('ADD_TODOS_SUCCESS');
    return state;

Let’s only take a quick look at our LOAD_TODOS_SUCCESS reducer which gets called by our fetchTodo() action. See here.

case 'LOAD_TODOS_SUCCESS':
    todos = Object.keys(action.json).map(k => {
        return {
            text: action.json[k].text,
            key: k,
        };
    });

    return Object.assign({}, state, {todos: todos});

We only do some normalisation and return a new state with the updated todos.

More questions? Take a look at and try our working example on GitHub!

That’s all for now. Thanks for reading.

Jalal Fathi is freelance software developer and startup founder. Passionate about web technologies and in love with Polymer. Learn more about how he can help you to create your next digital product. He works wherever he wants and tries to catch a good swell wherever he can. He wrote this bio by himself while writing in third person.

• Step 1: How to use Redux with Polymer 2
• Step 2: How to structure larger Polymer 2 apps with Redux Reselect
• Step 3: How to make async API calls in a Polymer 2 app using Redux Thunk middleware

Step-2 shows how to use Redux Reselect in a polymer app. If you already familiar with Redux Reselect and you want to learn more about calling API endpoints with Redux continue with Step-3!

// If you want to clone this tutorial:

git clone https://github.com/JaySunSyn/ReduxTodo.git

and make sure to uncomment the step-2 import in index.html

<!-- <link rel="import" href="/step-1/my-app.html"> -->
<link rel="import" href="/step-2/my-app.html">
<!-- <link rel="import" href="/step-3/my-app.html"> -->

In the previous post, we’ve put all redux logic into a singleredux-mixin.html file. ( see/step-1/ directory).

This can get quite messy because:

1. Reducers are most likely to get blown up.
2. In our Polymer elements we hard code the action types and statePaths. If something changes, we need to change it everywhere.
3. Don’t repeat yourself. If our requirements for an object’s normalisation changes, we want to execute that change in a single place.

So let’s create 3 more files:

Selectors

redux-selectors.html

First, let’s install reselect

npm install --save reselect

Selectors are like computed properties in Polymer. We create them centralised in our Polymer app. They can depend on multiple arguments and get re-computed if the respective state changes.

=> Selectors can compute derived data, allowing Redux to store the minimal possible state.

=> Selectors are efficient. A selector is not recomputed unless one of its arguments change.

=> Selectors are composable. They can be used as input to other selectors.

Let’s take a look at a light version of our selector code:

We have two selectors. todos which just returns the todos array of the state and todosUpper which returns an upper case version of our todos array. They get re-computed each time state.todo.todos changes.

Let’s take a look at how our <todo-list> element properties change when having selectors in place.

Before:

static get properties() {
    return {
        todos: {
            type: Array,
            statePath: ‘todos’, // hard coded
        },

    };
}

After:

static get properties() {
    return {
        todos: {
            type: Array,
            statePath: App.select.todos, // cool
        },

        // let's get also the upper case version    
        todosUpperCase: {
            type: Array,
            statePath: App.select.todosUpper,
        },
    };
}

We can now reference computed selectors in the statePath attribute of our elements - which is much cleaner.

Actions

redux-actions.html

In the previous post, we included respective actions into each element. Let’s add all actions to one file. At a later stage, we can include our actions getter into the ReduxMixin which will save us some writing work.

The code is quite straightforward:

Because we’ll include the actions getter into the mixin, we don’t have to write the getter in each and every Polymer element.

Reducers

Similar as with the actions, let’s just put the reducers into a separate file.

Nothing much changed here. We only make the Reducer available in the global space via App.rootReducer.

ReduxMixin

redux-mixin.html

The place where everything comes together.

Please notice that App.ReduxMixin is based on ActionsMixin where we define the actions getter.

Using it in our Polymer elements

We extend our element from App.ReduxMixin to include the Redux magic. Notice that we don’t have to write an actions getter anymore. We reference the action we dispatch with App.actions.remove and pass in our todo.

Way better, right?

Jalal Fathi is freelance software developer and startup founder. Passionate about web technologies and in love with Polymer. Learn more about how he can help you to create your next digital product. He works wherever he wants and tries to catch a good swell wherever he can. He wrote this bio by himself while writing in third person.

Next, learn how we can asynchronously call an API endpoint using a middleware.

Step 3: How to make async API calls in a Polymer 2 app using Redux Thunk middleware

I assume you’ve heard of Christopher Turner’s tur-nr/polymer-redux element. We are using his element and showcase a working todo list app.

Step-1 shows how to use polymer-redux. If you are already familiar with polymer-redux, continue with Step-2!

// If you want to clone this tutorial:

git clone https://github.com/JaySunSyn/ReduxTodo.git

Install dependencies

bower i -S tur-nr/polymer-redux

and redux itself with npm:

npm install --save redux

Create a folder named redux where we put in all our redux related files and create a file named redux-mixin.html.

In the current step of this tutorial, we pack everything into one file.

Creating the Reducer

A reducer is a pure function that takes the previous state and an action and returns the next state.

The most basic reducer is in the polymer-redux example which is a function taking state and action as attributes and always returns the same state.

(state = {}, action) => state

In our example, we want to modify the state depending on the passed in action. We then return (a copy) of the modified state.

Let’s go through the file step by step.

After importing the dependencies, we tell Redux what our initialState should look like. In our case, we predefine three todos.

const initialState = { 
    todos: [ 
        {text: ‘Buy Veggies’},
        {text: ‘Buy Fruits’},
        {text: ‘Buy Pizza’},
    ],
};

(We could also define our todos as an empty array and then load the actual todos from our server which we will discuss in step 3 of this tutorial.)

Next, we’ll define the reducer itself and return the initial state if our previous state is not defined.

if (!state) { return initialState; }

Now it’s time to check which action we should take to modify our state. For that, let’s switch through the action.type property.

const todos = state.todos.slice(0);

switch (action.type) { 
    case ‘ADD_TODO’: 
        todos.push(action.todo); 
    break;

    case ‘REMOVE_TODO’: 
        todos.splice(todos.indexOf(action.todo), 1); 
    break; 
}

We defined two actions. ADD_TODO adds a todo to the todos array and REMOVE_TODO removes one.

In Redux, we do not modify the passed in state but rather make a copy of the state, modify that copy and return a copy of the modified state.

return Object.assign({}, state, {todos: todos});

Now we only have to create the store as well as the mixin we will use in our Polymer elements.

const store = Redux.createStore(reducer);
const ReduxMixin = PolymerRedux(store);

We created ReduxMixin which we can use in our elements to give them redux magic.

The question you might have now is: How can we trigger the reducer to be called from our element?

Using the ReduxMixin in our elements

In our example, we have two elements using Redux.

<todo-list> and <todo-input>

Both of them work similarly. They only trigger different actions.

Let’s take a look at <todo-list>:

Now let’s take a step-by-step look at the file.

The first thing we notice is that TodoList extends our previously definedReduxMixin. Doing so, TodoList obtains Redux magic.

class TodoList extends ReduxMixin(Polymer.Element)

The one piece of unique syntax the ReduxMixin is going to give us is an additional attribute called statePath. What statePath is doing is to tell Redux what the path of this ‘todos’ property is in this big global state object. So in our case, the path is just ‘todos’.

static get properties() { 
    return { 
        todos: { 
            type: Array, 
            statePath: ‘todos’, 
        }, 
    }; 
}

Next thing to notice is that we added actions the same way as we added properties.

static get actions() { 
    return { 
        remove: (todo) => { 
            return { type: ‘REMOVE_TODO’, todo: todo, }; 
        }, 
    }; 
}

actions() returns an object with the remove attribute (we can call it however we want). The value is always a function which returns an object with a ‘type’ property and maybe some other properties we can reference from our reducer. In our case a ‘todo’ property.

How do we trigger the reducer function to get called?

this.dispatch(‘remove’, todo);

We call this.dispatch('name_of_action') to call the reducer with our action. The switch statement will be executed, etc. and the state will eventually get modified.

Yay! We did it.

Our other element TodoInput works similarly. Take a look at the file on GitHub!

Now run polymer serve -o and notice that our todos get listed without having bound them to any other polymer property. Try to click on a todo to check if the remove action works as expected.

Jalal Fathi is freelance software developer and startup founder. Passionate about web technologies and in love with Polymer. Learn more about how he can help you to create your next digital product. He works wherever he wants and tries to catch a good swell wherever he can. He wrote this bio by himself while writing in third person.

Next, see how we can structure larger Polymer apps, so it does not get messy if the app grows.

Step 2: How to structure larger Polymer 2 apps with Redux Reselect