Coercion Between Primitives and Objects in JavaScript

LV 🏳️‍🌈 — Fri, 11 Jan 2019 01:56:52 +0000

Every JavaScript developer has read at least one article that describes the unexpected values you get when you perform operations with mismatched types. This is not one of those posts. So relax, I won’t try to trip you up with type coercion examples.

The idea for this article was born while I was working with Flow, a type checker for JavaScript. While declaring types, I accidentally gave an argument type Boolean and not boolean. I realized there was a casual subtly to my mistake so I wanted to talk about why these two things aren’t the same.

The difference between String and string

There are six primitive types in JavaScript: boolean, string, number, null, undefined, and symbol. Right now we’ll focus on the first three. These three have wrapper objects called Boolean, String, and Number. You’ve probably used these special wrapper objects when doing an explicit type conversion, e.g.:

    let example = “6”;
    7 === 1 + Number(example)  // true

Since JavaScript is loosely typed, you use implicit type coercion between these types all the time, e.g:

    let example = “This is a string”;
    example.length  // 16

Here, the JavaScript interpreter sees that you are trying to use a primitive as an object by accessing a property. Since primitives don’t have properties, the interpreter wraps the string primitive in an object by calling String(example) in the background. This allows you to use the primitive like an object.

Boolean vs. boolean and why it matters

For the most part, we can use primitives and wrapper types the same way with no issue. But here’s a particular case where that’s not true.

    let example = new Boolean(false);
    if (example) {
        console.log(‘Cats are the best’);
    } else {
        console.log(‘Dogs are the best’);
    }

Go ahead and try this example in your console right now.

You might be surprised to see that it prints out ‘Cats are the best’! Since all objects are truthy in JavaScript, example evaluates to true, which can be unintuitive.

Now you know one the reasons why Flow doesn’t let you use primitive and wrapper types interchangeably. I suggest playing around with this over at Flow's playground.

Creating Notifications with React Create Portals

LV 🏳️‍🌈 — Tue, 01 Jan 2019 21:20:03 +0000

Feel free to jump straight to my CodePen example. This post also appears on my personal blog.

When developing UI with components, the tendency is to think from the outside in. Especially with React, it almost always starts with an app shell component, page components, and then smaller components. This can make it challenging when you have to build elements that "pop out" of this paradigm. Where do you place these components?

React Portals create a simple solution to this problem. It allows you to think "outside" your app and render components outside your app shell, but still have those components share state with your app.

In this tutorial, I'll walk you through building a simple notification component that you can use as the basis of any notification, modal, or chat bubble style UI element.

The first thing you need to do is make a new HTML element in your app in which your notification will be rendered.

    <div id="root">
        <!-- This is your app root. You have this (maybe with a different id) already. -->
    </div>
    <div id="portal">
        <!-- This is new! It's where your new notification element will be rendered. -->
    </div>

The second thing you need to do is create a container element for your notification. This is the cool part! This is the element you declare inside your app that is rendered outside the app root.

    class NotificationContainer extends React.Component {
      render() {
        // grab the new element you declared above
        const domElement = document.getElementById('portal');
        return ReactDOM.createPortal(
          this.props.children,
          domElement
        );
      }
    }

Now your notification container needs some content inside. Let's make a component for that.

    class Notification extends React.Component {
        render() {
            return (
            <div> The world says hello! </div>
            )
        }
    }

Alright, we have all the new necessary components, so let's actually use them.

    // this is the app root that's being rendered inside that div with id="root".
    class App extends React.Component {
        render() {
            return (
                <div>
                    <h1>Hello world!</h1>
                    <NotificationContainer>
                        <Notification/>
                    </NotificationContainer>
                </div>
            );
        }
    }

Congrats, you just made a notification! Of course, you will probably want to throw some styling on it but the basics are there.

Here are some cool benefits to building notifications this way:

You can use the state of your app to control the notification. This can let you do things like:
- delay the notification / have it on a timer.
- swap out the child of the NotificationContainer so you can render different components
- display information from your app state in your easily
This simplifies CSS a little bit. It can be annoying to wrangle the CSS of notifications from inside your app, this makes it easier by bringing the div to the same level as your app root.

If you want to see an example of using state to delay the notification pop up, here is my CodePen that builds off this example.

DEV Community: LV 🏳️‍🌈

Coercion Between Primitives and Objects in JavaScript

The difference between String and string

Boolean vs. boolean and why it matters

Creating Notifications with React Create Portals