Forem: Shawn Reisner

Here's Why Mapping a Constructed Array in JavaScript Doesn't Work

Shawn Reisner — Fri, 15 Jun 2018 16:14:16 +0000

Why Mapping a Constructed Array Doesn’t Work in JavaScript

And How To Do It Correctly

Scenario

For the sake of demonstration, suppose you need to generate an array of numbers from 0 to 99. How might you do this? Here’s one option:

const arr = [];

for (let i = 0; i < 100; i++) {
  arr[i] = i;
}

If you’re like me, seeing a traditional for-loop in JavaScript makes you slightly uncomfortable. In fact, I haven’t written a traditional for-loop in years thanks to higher-order functions such as forEach, map, filter, and reduce. Declarative functional programming for the win!

Maybe you haven’t yet drunk the functional programming Kool-aid and you’re thinking the above solution seems perfectly fine. It technically is, but after you’ve had a taste of the magic of higher-order functions, you’re probably thinking, “There must be a better way.”

My first reaction to this problem was, “I know! I’ll create an empty array of length 100 and map the indices to each element!” JavaScript allows you create an empty array of length n with the Array constructor, like this:

const arr = Array(100);

Perfect, right? I have an array of length 100, so now I just need to map the index to each element.

const arr = Array(100).map((_, i) => i);

console.log(arr[0] === undefined); // true

What the h*ck!? The first element of the array should be 0, but it’s actually undefined!

Explanation

There’s an important technical distinction I need to make here in order to explain why this happened. Internally, JavaScript arrays are objects, with numbers as keys. For example:

['a', 'b', 'c']

is essentially equivalent to this object:

{
  0: 'a',
  1: 'b',
  2: 'c',
  length: 3
}

When you access the element at index 0 in an array, you’re really just accessing an object property whose key is 0. This is important because when you think of arrays as objects in conjunction with the way these higher-order functions are implemented (don’t worry, I did that part for you), the cause of our problem makes perfect sense.

When you create a new array with the Array constructor, it creates a new array object with its length property set to the value you passed in, but otherwise the object is a vacuum. There are no index keys in the object representation of the array whatsoever.

{
  //no index keys!
  length: 100
}

You get undefined when you try to access the array value at index 0, but it’s not that the value undefined is stored at index 0, it’s that the default behavior in JavaScript is to return undefined if you try to access the value of an object for a key that does not exist.

It just so happens that the higher-order functions map, reduce, filter, and forEach iterate over the index keys of the array object from 0 to length, but the callback is only executed if the key exists on the object. This explains why our callback is never called and nothing happens when we call the map function on the array — there are no index keys!

Solution

As you now know, what we need is an array whose internal object representation contains a key for each number from 0 to length. The best way to do this is to spread the array out into an empty array.

const arr = [...Array(100)].map((_, i) => i);

console.log(arr[0]);
// 0

Spreading the array into an empty array results in an array that’s filled with undefined at each index.

{
  0: undefined,
  1: undefined,
  2: undefined,
  ...
  99: undefined,
  length: 100
}

This is because the spread operator is simpler than the map function. It simply loops through the array (or any iterable, really) from 0 to length and creates a new index key in the enclosing array with the value returned from the spreading array at the current index. Since JavaScript returns undefined from our spreading array at each of its indices (remember, it does this by default because it doesn’t have the index key for that value), we end up with a new array that’s actually filled with index keys, and therefore map-able (and reduce-able, filter-able, and forEach-able).

Conclusion

We discovered some of the implications of arrays being internally represented as objects in Javascript, and learned the best way to create arrays of arbitrary length filled with whatever values you need.

As always, leave your comments, questions, and feedback below!

Happy coding! 👍

Follow me!

If you liked this post, follow me! Or at least throw me a clap or two. You can spare one measly clap, right?

Medium : @shawn.webdev
Twitter : @ReisnerShawn
dev.to : @sreisner
Instagram : @shawn.webdev

Check out more of my work

Learn the React Context API with a Practical Example You Can Bring to Your Apps

Shawn Reisner — Thu, 14 Jun 2018 01:34:48 +0000

Preface

Most apps need a way to unobtrusively display notifications to users as they happen. Suppose you're running a 20% off sale and you'd like to let your users know as soon as they sign in, or maybe after they submit feedback you want to display a thank you message.

Material UI provides a snackbar component which is great for these types of messages, so I'll be using that for this example. That being said, this article is much more about the Context API than Material UI, and swapping out Material UI for any other component library would be very simple with this approach.

Many apps need to trigger messages from dozens of different components. The React Context API makes it dead simple to provide all components access to a shared snackbar so they can trigger these messages without needing to implement separate components for each message. Here's how.

What We’re Building

Setup/Dependencies

This post assumes you already have a React app set up with @material-ui/core 1.0.0+ and @material-ui/icons 1.0.0+ installed as dependencies.

Creating the Context

First, we need to create our Context API provider and consumer components. The provider provides the state of our snackbar, as well as some functions for manipulating that state, to all consumers. This allows all child components to access and manipulate the provider ’s state no matter how deep they are within the component hierarchy. No prop drilling required!

The first step is creating a context by calling React.createContext(). The object returned contains two properties, Provider and Consumer. We use these to build out the components that will manage and interact with the snackbar’s state.

From here on out, when I use the terms “provider” and “consumer”, I’m referring to the SharedSnackbarProvider and SharedSnackbarConsumer components from this section.

As you can see, our provider is a pretty standard component. In its render function, we render a SharedSnackbarContext.Provider component with a value prop. The object passed to the value prop is what consumers will be able to access so they can interact with our snackbar. For lack of a better term, this is the API for our shared snackbar component.

Take note of the TODO on line 41. Eventually we’ll be rendering the actual snackbar within the context provider’s render function as a sibling to its children. This ensures that when the provider is rendered, all children will be using the same exact snackbar component.

Creating the Shared Snackbar Component

Now we need to build the presentation component responsible for rendering the snackbar UI based on the state of the provider. This component will use the consumer to access the properties it needs for rendering.

Here we’ve built a component that renders the snackbar UI in a function within the SharedSnackbarConsumer component. The argument to the function is the value prop object we exposed from our provider. As a result, when the state of the provider is updated, it will trigger the snackbar component to rerender.

Now we can render this component in our provider’s render function.

Rendering the Provider

At this point, we’re almost finished with the infrastructure. There’s just one last thing to do, which is to render the provider within our app. I’m going to place the provider at the root of the entire app so that all children have access to the snackbar.

Opening the Snackbar from Child Components

Now, ButtonA and ButtonB can render their UI and trigger in-app messages without needing to directly receive props from the root of the app! 🤙

Summary

In summary, here’s what happening.

First, we created a context provider component which manages the global state for our snackbar.
We then created a component that renders the snackbar’s UI based on the state of the provider. This component subscribes to the provider state in its render function via a context consumer.
Finally, we rendered two buttons that update the state of the context provider with the openSnackbar function, which was passed to them via a context consumer. This results in the changes propagating down to the snackbar component, triggering a re-render.

Material UI provides a number of other snackbar features I did not implement with this example, such as action buttons and color customization. For the sake of simplicity I didn’t add the ability to customize those features. Adding that logic yourself would be a great next step if you’re really looking to learn the Context API!

Thank you so much for taking the time to improve yourself. If you found this article useful in any way, I will always accept a clap or two. While you’re at it, take a few seconds and follow me for more great content:

Twitter : @ReisnerShawn

dev.to : @sreisner

Instagram : @shawn.webdev

Happy coding!

A Quick, Practical Use Case for ES6 Generators: Building an Infinitely Repeating Array

Shawn Reisner — Wed, 06 Jun 2018 13:06:07 +0000

Preface

You’ve probably heard of ES6 generators, perhaps you’ve even learned the syntax, and you may be wondering what they’re actually useful for in real life.

Definition (from MDN)

Generators are functions which can be exited and later re-entered. Their context (variable bindings) will be saved across re-entrances.

You may be thinking, “Okay, but why would I want to do that?” As it turns out, there are a whole range of use cases ranging from simple to complex, many of which involve Promises to make asynchronous requests (async/await is built on top of generators). My goal is to give you the first baby step into understanding how they work with a simple, real-life example so that you begin noticing when a generator is the most suitable solution to problems in your own code. Here we go.

Use Case

I’m building an app in which my users can calculate a 3-week workout cycle, with a setting to work out between 3 and 7 days per week during the cycle. Each individual workout is based on one of the following 4 lifts: squat, bench press, deadlift, and overhead press, and each successive workout must be based on the next lift in that order:

Squat
Bench
Deadlift
Overhead press
Squat
Bench
Deadlift
Overhead press
…

You can probably see where this is going.

I need my code to say, “Give me the lift for the next workout, then the next, then the next, etc. When the end of the list of lifts is reached, start over from the beginning and keep repeating forever, until I’ve generated all the workouts for the 3-week cycle.” Here’s a simplified version of how I initially implemented it, without generators:

Not too bad, but it could be more declarative. Wouldn’t it be nice if we didn’t have to keep track of that currentLiftIndex directly in our workout generation code? It decreases the readability of the code and feels like it belongs in its own function. Here’s the code using a generator function, I’ll explain it below.

Here, the code is more declarative and readable. We abstracted the index-tracking logic into a general-purpose utility function called repeatedArray. The function * syntax tells JavaScript that this is a generator function. All we have to do is ask for the next item in the “repeated array” and our generator gives it to us. The best part is we don’t have to worry about how it’s happening outside of our generator function.

Here’s what’s happening:

repeatedArray returns an iterator object for the repeatedArray function itself (read that twice) when we call it on line 9. The iterator is stored in a variable named nextLiftGenerator. It’s important to understand that the code in the function hasn’t been executed at this point. The function is only executed when we call the next() function on the nextLiftGenerator iterable, and it’s only executed up until it hits a yield. Our generator gives us the value, then waits until the next call to continue execution until it hits another yield, then returns that value. Make sense? That’s it!

This is obviously a very simple example, but hopefully it helped you understand how generators work, and also why generators are such a powerful feature in JavaScript.

If you liked this article, follow me on Twitter and Instagram for more nerdy content!

Happy coding!

Building a “Mask Toggle” Password Input Component w/ React and Material UI

Shawn Reisner — Mon, 04 Jun 2018 17:03:13 +0000

As everyone knows by now, allowing users to toggle password input visibility removes friction and improves user experience. I’ll show you how to build a toggleable password input in this tutorial!

Setup/Dependencies

This article assumes you already have a React app set up with @material-ui/core 1.0.0+ and @material-ui/icons 1.0.0+ installed as dependencies. If you need help with this this, start here, then go here.

Building the Component

First, we start with our PasswordInput class component that renders a Material UI TextField.

Here we’ve got ourselves a standard password input.

It’s worth noting that I spread the component’s props onto the rendered TextField. This allows you to treat the PasswordInput component just as you would a TextField component with a type of password.

Before getting into the mask/unmask button logic, it’s important to understand that in Material UI, the TextField component is basically just a wrapper around an Input component. Since you might want to customize the underlying props of the Input , Material UI provides a prop on the TextField called InputProps that lets you pass custom props through the TextField and into the underlying Input. Make sense? It just so happens that the Input component has an important prop we need to pass to it through the TextField , called endAdornment. Here’s the code.

Take a look at lines 15–31. This gives us a nice icon embedded to the right within the input. Let’s make it actually toggle the mask.

Here we added a passwordIsMasked state property to the component and then toggle it when the eye is clicked. When the property is toggled, it triggers a rerender of the component as either password or a text input.

Styles were added to the icon to change the cursor to a pointer when the user clicks it as well.

And there you have it, we’re done!

If you found this post useful, feel free to throw some applause my way, leave a comment, or follow me on here or on social media (my Instagram is on fire lately)!