Forem: Daniel Wagener

Forks and Pull Requests: How to Contribute to Github Repos

Daniel Wagener — Sat, 22 Aug 2020 17:15:03 +0000

I recently worked with a team that was lacking a bit of documentation, so I took it upon myself to create some. In the process, I gained sympathy for authors of documentation. Documentation can often seem incomprehensible, and that's in part because when you write documentation, you have to assume your audience has some baseline level of knowledge. We can all agree, your project's README isn't the place to explain if/else statements! So I wrote some documentation outlining the steps required to make a pull request… only to realize some people on my team didn't know what a pull request was. Whoops. So let's clear that up!

The Problem with Collaborative Repositories

If you're reading this article, I'm going to assume you've used Github before. You've made a personal repository for your own code, created commits, and then pushed those commits to that repository. This is a fantastic milestone in your development journey! Now you want to contribute to someone else's repository. Perhaps this repository is open source, or perhaps it is a team's repository. Okay, but simple enough, right? Let's just clone this repo and push commits to it, just like you did with your personal repo.

BUT WAIT! That's dangerous territory. What if someone pushes error-filled code to this shared repository? Or even worse, what if some malicious Github user intentionally breaks the app with pernicious code? We can't have that! Therefore, this collaborative repo needs one or more trusted maintainers that review all incoming changes. Now the question is: how do you run your code by these maintainers?

Answer: You Make a Fork

A fork is simply a copy of the repo that lives on your own personal Github profile. You can make any changes you want to this fork and experiment all you want with its code, and that's fine! Any changes you make to your fork have no effect on the original (henceforth, "upstream") repository you forked from. In fact, the only way your changes make it into the upstream repo is through pull requests.

"Pull requests? Tell me more!"

Let's say you code an awesome feature for the project. You make your final commit and push it to your fork. Great work! Now we just need to show your awesome feature to the upstream repo maintainers so it can get included in the project.

If you make a pull request, the maintainers can look at your new code, make sure it jives with the rest of the project, and then merge it into the upstream. And if your code doesn't 100% jive just yet, the maintainers can comment on your pull request to tell you what you need to fix.

Sounds great, right? Now let's learn how to get this done.

Making a Pull Request

I actually have to make a pull request today. It's super simple and doesn't even involve code! I'm just updating the README to let my team members know I'm no longer actively working on the project (sad day). Let's make this pull request together.

To the fork!

I've been working on this project for a while, and I already have a fork. If you don't have a fork for the project you want to contribute to, you'll have to make one by clicking the Fork icon in the top right of the repo:

Then, of course, you'll run git clone on your new fork (not the upstream!) to download it to your computer. After you clone, you'll have to run git remote add upstream insert_upstream_repo's_url_here to connect your local repo to the upstream repo. After you've done so, you can run git remote -v to make sure you have both origin and upstream remotes.

Now let's begin! If you've literally just cloned a new fork, this first step doesn't apply to you. But imagine you've had this repository on your computer for a while, and since you last contributed to it, other people have made changes to the upstream repo. Perhaps they've written code that's going to affect the way you approach your issue. Perhaps someone has already solved the issue you were about to solve! In any case, we don't want to be working with outdated code. We want the latest and freshest code on our computer before we start working on anything.

Getting the Latest Code

To get this most current code, we'll run two commands. First, we have to download the upstream repo's code. Here's how:

git fetch --all

Easy, right? Though if you want to specify that you only want to download from upstream, you'd you'd run:

git fetch upstream

Note that this works because we defined upstream earlier when we ran git remote add upstream whatever_the_upstream's_url_was.

So now we've downloaded the upstream's code! But hold up. Our code doesn't look any different. Well, we've downloaded the code, but we still have to merge it into our local project. Let's do that now:

git merge upstream/master

Excellent! You should now see that the code on your computer is the same as the upstream repo's master branch. Great job getting this far.

One last step! If the project is using something like npm or Yarn, someone might have added an npm package since you last worked on the code. Therefore, to get everything running correctly, we need to add those new packages:

npm install
*****OR*****
yarn install

"What about git pull?"

Git has a command, git pull, that actually has nothing to do with making a pull request. That command is simply a combination of the git fetch and git merge upstream/master commands we just ran. All this Git stuff is actually way more intricate than I'm making it sound, so if you'd like, you can read more about fetching and pulling.

Making a Change

Whew! Now let's code our new feature. Whenever we code a new feature, it's best practice to make a new branch. That way, if everything devolves into a fiery mess, we can always escape by going back to our master branch.

The process of navigating between branches and commits is called a git checkout. Here's a neat command that lets us create a new branch and checkout it immediately:

git checkout -B your_new_branch_name_here

Like I said, I'm removing my name from the README, so I'll make my branch:

I make the changes to the README, and then commit and push my changes:

Note that since I made a new branch, I'm running git push origin remove_daniel instead of git push origin master. Also note that here, origin is my fork. Again, if you get lost, git remote -v is your friend.

We're almost there! Time for…

The Actual Pull Request

If I now go to Github and navigate to the upstream repo, I'll probably see this notification:

Github makes things easy, thankfully. But if you don't see this notification for some reason, no problem! Just click on the "Pull requests" tab and click the green "New pull request" button.

We don't see our fork anywhere, and that's because we have to click "compare across forks." Now you'll see dropdowns for two repositories: the base repository and the head repository. In this scenario, the base repository is the upstream repo and the head repository should be my fork. Thus, I go to the second set of dropdowns and select my repo and branch accordingly:

At last! I now click "Create pull request" so the maintainers can see my changes.

Accepting and Merging a Pull Request

As it so happens, I am (for now) a maintainer of the repo I just contributed to. So from a maintainer's perspective, here's what the new pull request looks like:

As a maintainer, I can click on a commit to inspect the changes that were made. I also have the ability to leave a comment, among other things. If I decide everything looks good, I click "Merge pull request" to complete the process.

We're done! My update is now in the upstream repo. The concept of pull requests should be demystified now that you've seen one in action from beginning to end.

Hope this helps!

Follow me on LinkedIn, GitHub, and Twitter.

React Native vs. React: Basic Syntax

Daniel Wagener — Mon, 10 Aug 2020 14:45:09 +0000

I've just started taking Stephen Grider's React Native course, and he explains a lot of React and JSX concepts to people who might not be familiar with them. If you're like me and already know React, read on for just the info specific to React Native.

React Native Elements - The First Three

Let's have a look at this React Native Component:

import React from 'react';
import { Text, StyleSheet, View } from 'react-native';

const ComponentsScreen = () => {
  const name = 'Daniel';
  return (
    <View>
      <Text style={styles.headingStyle}>Getting started with React Native</Text>
      <Text style={styles.greetingStyle}>My name is {name}</Text>
    </View>
  );
};

const styles = StyleSheet.create({
  headingStyle: {
    fontSize: 45
  },
  greetingStyle: {
    fontSize: 20
  }
});

export default ComponentsScreen;

A few new things here! Let's break down that React Native import statement.

Text

Any time we want to show some text to the user, we have to wrap in in a Text component. Any text we try to display outside of this component will result in an error.

StyleSheet

To give our elements CSS styling, we create style objects (just like we would in React), put them all into a bigger object, and then pass that object into StyleSheet.create(). You might be thinking, "Why can't we just define styles inline?" The good news is, we can! However, if we define a non-React-friendly property (like fontsize), StyleSheet.create() will catch it and throw an error for us. We miss out on this check if we define styles inline.

View

If we want to render multiple JSX elements, we have to wrap them in a View component. In React we could have just used div tags, but those would result in an error in React Native.

FlatLists

When we want to render a list of JSX elements from an array in React, we're used to using a map method. In React Native, we have to switch gears and make use of an element called FlatList.

import React from 'react';
import { View, Text, StyleSheet, FlatList } from 'react-native';

const ListScreen = () => {
  const friends = [
    { name: "Friend A" },
    { name: "Friend B "},
    { name: "Friend 4" },
  ]
  return <FlatList data={friends} renderItem={element => {
    //some code here
  }}/>;
};

const styles = StyleSheet.create({});

export default ListScreen;

Looking at this element, the data attribute is easy enough to grok, but what about the renderItem attribute? Is that the same as a map function? Unfortunately, no. In the first iteration of renderItem, element would look like this:

{
   item: { name: "Friend A" },
   index: 0
}

If we're only interested in the item value, we can use a bit of ES6 destructuring:

const ListScreen = () => {
  const friends = [
    { name: 'Friend A' },
    { name: 'Friend B ' },
    { name: 'Friend 4' }
  ];
  return (
    <FlatList
      data={friends}
      renderItem={({ item }) => {
        return <Text>{item.name}</Text>;
      }}
    />
  );
};

Of course, just like in React, we have to define a key attribute every time we render a list. If we don't feel like declaring a key property for every item in our friends array, we can take advantage of React Native's keyExtractor method:

return (
    <FlatList
      keyExtractor={friend => friend.name}
      data={friends}
      renderItem={({ item }) => {
        return <Text style={styles.textStyle}>{item.name}</Text>;
      }}
    />
  );

I know: "Ughhh, why can't we just use the map method?" Well, the upshot of FlatList is that we can add a couple of attributes to easily turn the list horizontal (think Netflix tiles!). Check it out:

return (
    <FlatList
      horizontal
      showsHorizontalScrollIndicator={false}
      keyExtractor={friend => friend.name}
      data={friends}
      renderItem={({ item }) => {
        return <Text style={styles.textStyle}>{item.name}</Text>;
      }}
    />
  );

Buttons

In the beginning of React Native, a component called TouchableOpacity was the sole equivalent of a button. It's powerful and allows for a lot of customization. However, it's not super intuitive, and a lot of developers starting out with React Native got hung up looking for a Button component, so the React Native team added one. It's essentially a simpler version of TouchableOpacity.

Button components

A React Native Button component, unlike an HTML button, is a self-closing element. To render text inside it, we pass in a string as a title attribute.

import React from 'react';
import { Text, StyleSheet, View, Button } from 'react-native';

const HomeScreen = () => {
  return (
    <View>
      <Text style={styles.text}>Hi there!</Text>
      <Button title='Go to Components Demo' />
    </View>
  );
};

A nice benefit of Button components is that they render with some styling right out of the box: blue text on iOS or white text on a blue background on Android.

TouchableOpacity

A TouchableOpacity, on the other hand, comes with no styling out of the box, save for a momentary fade-out effect when it is pressed. To make things confusing, TouchableOpacity is NOT a self closing component, and we have to render some other element or elements between the tags.

import React from "react";
import { View, Text, Button, TouchableOpacity } from "react-native";

const HomeScreen = () => {
  return (
    <View>
      <Text style={styles.text}>Hi there!</Text>
      <Button title='Go to Components Demo' />

      <TouchableOpacity>
        <Text>Go to List Demo</Text>
      </TouchableOpacity>
    </View>
  );
};

Adding functionality

In React, we're used to giving buttons an onClick attribute with a callback function. We don't have a mouse to click with when we're using our phones, so the React Native equivalent is called onPress. Here's what that might look like using the navigation method from react-navigation-stack (specifics later in the article!):

import React from "react";
import { View, Text, StyleSheet, TextInput } from "react-native";

const HomeScreen = ({ navigation }) => {
  return (
    <View>
      <Text style={styles.text}>Hi there!</Text>
      <Button
        onPress={() => navigation.navigate('Components')}
        title='Go to Components Demo'
      />
      <TouchableOpacity onPress={() => navigation.navigate('List')}>
        <Text>Go to List Demo</Text>
      </TouchableOpacity>
    </View>
  );
};

Images

React Native also has a primitive element for images called Image. To render a local image, we pass the relative path into a require() function and assign it to the source attribute. Be careful: this is the full word source, not src!

import React from "react";
import { View, Text, Image } from "react-native";

const ImageDetail = props => {
  return (
    <View>
      <Image source={require('../../assets/beach.jpg')} />
      <Text>{props.title}</Text>
    </View>
  );
};

One catch is that source has to be a static value. That means can’t write <Image source={require(props.img)} /> — instead, we’d have to pass down the entire require('../../assets.beach.jpg') function call as a prop.

Inputs

Adding a text input element seems pretty easy at first glance:

import React from "react";
import { View, TextInput } from "react-native";

const TextScreen = () => {
  return (
    <View>
      <TextInput />
    </View>
  );
};

However, if we run this file as is, it’ll look like a blank screen. The TextInput is actually there and we can interact with it, but it has zero default styling: no borders, no background, nothing. Let’s take care of that now:

const TextScreen = () => {
  return (
    <View>
      <TextInput style={styles.input} />
    </View>
  );
};

const styles = StyleSheet.create({
  input: {
    margin: 15,
    borderColor: "black",
    borderWidth: 1
  }
});

In addition, phones have auto-capitalize and autocorrect features we might not want to apply to our input. They’re both easy enough to disable:

const TextScreen = () => {
  return (
    <View>
      <TextInput
        style={styles.input}
        autoCapitalize='none'
        autoCorrect={false}
      />
    </View>
  );
};

You might’ve expected autoCapitalize to be a boolean, but it’s not because we actually have a few capitalization schemes to choose from ( sentences, characters, words).
Next, we’re going to want to make this input a controlled input. In other words, we want to connect the input’s value and the component’s state, just like in React. In React, we have an event listener attribute called onChange and we set the state equal to event.target.value. In React Native, that listener is called onChangeText and simply receives a newValue as a parameter instead of an entire event object.

const TextScreen = () => {
  const [name, setName] = useState("");

  return (
    <View>
      <Text>Enter name:</Text>
      <TextInput
        style={styles.input}
        autoCapitalize='none'
        autoCorrect={false}
        value={name}
        onChangeText={newValue => setName(newValue)}
      />
      <Text>My name is: {name}</Text>
    </View>
  );
};

One last note: the React Native equivalent of onSubmit for text inputs is onEndEditing.

Navigation with react-navigation

I originally wasn’t going to talk about specific libraries in this article, but I figured anyone reading this would probably be wondering about it.

The react-navigation library is now in v5 with breaking changes, but yarn add react-navigation installed v4 when I ran it. Apparently v5 has been released but is still in beta or something. The react-navigation has documentation for upgrading to v5 if you’d like. Anywho, assuming you’ve created a React Native app with the Expo CLI, you can run this command to get some helper libraries:

expo install react-native-gesture-handler react-native-reanimated react-native-screens react-native-safe-area-context @react-native-community/masked-view

Also, we’ll need to install these:

yarn add react-navigation-stack @react-native-community/masked-view

Now we can get coding! First, we write a couple of imports:

import { createAppContainer } from "react-navigation";
import { createStackNavigator } from "react-navigation-stack";

Note that createStackNavigator used to be in react-navigation, but now we have to import it from react-navigation-stack.

To get started, we declare a constant called navigator (by convention) and assign it a createStackNavigator call. This function takes two arguments, both objects: the first lists all our route names with their respective components, and the second defines other options.

Let’s tackle that first object argument. Assume we create a component called SearchScreen. To make our app open to the search screen, we import it into App.js and assign it to some (relevant) key in our object:

{
   Search: SearchScreen
}

Then, to make our app open up to SearchScreen when it launches, we specify so in the second object. We can define other things as well, like the title we’d like in our header.

{
   initialRouteName: "Search",
   defaultNavigationOptions: {
      title: "Business Search"
   }
}

Finally, we export our whole component by passing it in to createAppContainer. The whole App.js file would like this:

import { createAppContainer } from "react-navigation";
import { createStackNavigator } from "react-navigation-stack";
import SearchScreen from "./src/screens/SearchScreen";

const navigator = createStackNavigator(
  {
    Search: SearchScreen
  },
  {
    initialRouteName: "Search",
    defaultNavigationOptions: {
      title: "Business Search"
    }
  }
);

export default createAppContainer(navigator);

So now how do we actually perform navigation? Easy enough: our child components are now going to receive navigation as a prop, and that prop contains a navigate method. If we wanted to navigate back to SearchScreen, we’d simply pass the string 'Search' into navigation.navigate(). Hopefully this example from earlier makes more sense now:

import React from "react";
import { View, Text, StyleSheet, TextInput } from "react-native";

const HomeScreen = ({ navigation }) => {
  return (
    <View>
      <Text style={styles.text}>Hi there!</Text>
      <Button
        onPress={() => navigation.navigate('Components')}
        title='Go to Components Demo'
      />
      <TouchableOpacity onPress={() => navigation.navigate('List')}>
        <Text>Go to List Demo</Text>
      </TouchableOpacity>
    </View>
  );
};

Hope this helps!

Follow me on LinkedIn, GitHub, and Twitter

Interview Question: What is React?

Daniel Wagener — Thu, 02 Jul 2020 23:46:04 +0000

Recently in an interview I was asked, “What is React?” And it was funny, because I know how to use React, but I had a hard time selling it or explaining why it’s good. I mentioned components and fast page updates, but I couldn’t pull everything into a cohesive response. Thus, I decided I’d knock this question out of the park, once and for all. And so can you, since you’re reading this article!

So imagine an interviewer asks you:

“What is React?”

React is a Javascript library. Back in the early 2000’s, a Javascript library called jQuery was all the rage: it streamlined the implementation of Javascript and allowed developers to make increasingly complex web applications. As this complexity increased even further, large tech companies realized they needed an even better solution than jQuery. So, Google made AngularJS and Facebook made React, released in 2013.

“What problems does React solve?”

The short answer is that React allows us to create websites that perform fast, and allows us to create them faster. Specifically:

Component Architecture

A revolutionary idea in React is the idea of component architecture. Before React, we’d write a DOM tree in HTML (e.g. the head followed by the body, which contains a header, which itself contains an h1, and below that a p tag, etc). With React, we can make each visual part of the web app its own self-contained component. Then, we can place these components side-by-side like Lego blocks or even render components inside other components. These components make the development process faster. Not only that, they ultimately make the web app feel faster to its users. Here’s how:

Declarative Programming and State

jQuery uses an imperative style of programming, meaning it reaches into the DOM and changes elements directly. This style has a couple of problems. First off, changing individual DOM elements is an “expensive” process: relatively speaking, it takes a lot of time and resources. Also, if some parts of the web app needs to change based on others parts of the app, we developers potentially have to keep track of an intricate trail of changes.

React uses a declarative style of programming, which means that we developers change pieces of data and React accordingly figures out how our app should look. These pieces of data live in something called state. When we change the state of our app (e.g. updating a user’s login status), that change propagates through the relevant components in something called the virtual DOM, which is simply a Javascript representation of the real DOM. Like I said, updating the real DOM is expensive, so we want to update the virtual DOM first.

After the virtual DOM updates, React looks at those changes and uses a sophisticated internal algorithm to determine exactly which parts of the real DOM it needs to re-render. The upshot is that page re-renders happen as quickly and efficiently as possible, which is a great user experience. The users win, the developers win, the company saves money, everybody wins, and that’s why we use React.

Hope this helps, and thanks for reading!

Follow me on LinkedIn and GitHub

Ellipses, Three Dots, …, or Three Periods in Javascript — A Primer to the Spread Operator

Daniel Wagener — Mon, 09 Mar 2020 16:45:06 +0000

This isn’t the first article about the spread operator and it won’t be the last. Nevertheless, if you’re someone who’s confused about those cryptic ellipses in Javascript and you’ve stumbled upon my article amongst all others, welcome! I’ll guide you through it.

What is the spread operator?

The spread operator looks like ... and, in a nutshell, transforms an array (or object) into just its elements.

let arr = [1, 2, 3];

console.log(...arr); // 1 2 3

This syntax is new in ES6, so you may not have encountered it if you learned Javascript through outdated materials.

That’s nice, but how do I use it?

Glad you asked! Here are some ways that the spread operator makes our lives easier.

Copy an Array

The most basic (but not the easiest) way to copy an array is with a for loop:

let arr = [1, 2, 3];

let copyOfArr = [];

for (let i = 0; i < arr.length; i++) {
   copyOfArr.push(arr[i]);
}

console.log(copyOfArr); // [1, 2, 3]

A more savvy approach uses Array.slice():

let arr = [1, 2, 3];

let copyOfArr = arr.slice(0);

console.log(copyOfArr); // [1, 2, 3]

But, the easiest way is with the spread operator:

let arr = [1, 2, 3];

let copyOfArr = [...arr];

console.log(copyOfArr); // [1, 2, 3]

The spread operator takes the individual elements of arr and spreads (puts) them in our new array. Note that this is different from writing [arr]:

// NOT WHAT WE WANT

let arr = [1, 2, 3];

let copyOfArr = [arr];

console.log(copyOfArr); // [[1, 2, 3]]

“But why can’t we just write let copyOfArr = arr?”

Good question. The answer is, you absolutely can in some situations. HOWEVER, Javascript arrays and objects are passed by reference, not by value. This means that when we write let copyOfArr = arr, our new variable copyOfArr isn’t actually a copy of arr — it’s a reference that points to arr. So, if we change arr, then copyOfArr changes as well.

let arr = [1, 2, 3];

let copyOfArr = arr;

arr.pop();

console.log(copyOfArr); // [1, 2]

My guess is that if we wanted copyOfArr to change every time arr changes, we probably wouldn’t have made a copy in the first place.

Add an Element to the End of an Array

Now that we understand copying, these next examples will be easier. Suppose we want a new array with all the contents of arr, except now with a new element at the end. This sounds like a job for Array.push().

let arr = [1, 2, 3];

let newArray = [...arr];

newArray.push(4);

console.log(newArray); // [1, 2, 3, 4]

However, as it turns out, the spread operator is so powerful we don’t even need Array.push()! We’ll use the spread operator to create a new array with all the values of arr, followed by our new element or elements:

let arr = [1, 2, 3];

let newArray = [...arr, 4];

console.log(newArray); // [1, 2, 3, 4]

Add an Element to the Beginning of an Array

You probably see where this is going:

let arr = [1, 2, 3];

let newArray = [0, ...arr];

console.log(newArray); // [0, 1, 2, 3]

Put an Array’s Values in the Middle of a New Array

We can combine the above two use cases:

let arr = [1, 2, 3];

let newArray = [0, ...arr, 4, 5];

console.log(newArray); // [0, 1, 2, 3, 4, 5]

Concatenate (Merge) Arrays

Combining arrays is easier than ever with spread syntax:

let oneTwo = [1, 2];

let threeFour = [3, 4];

let newArray = [...oneTwo, ...threeFour];

console.log(newArray); // [1, 2, 3, 4]

Get the Highest Value of an Array

I’ve seen programmers sort arrays from highest to lowest and then return the first element of the sorted array.

let values = [4, 1, 2, 5, 0];

let highestValue = values.sort((a, b) => b - a)[0];

console.log(highestValue); // 5

If you want to be fancy, here’s a solution that uses Array.reduce():

let values = [4, 1, 2, 5, 0];

let highestValue = values.reduce((acc, val) => (val > acc ? val : acc), 0);

console.log(highestValue); // 5

However, the most logical solution would be to use Math.max(). The catch is, we have to pass in separate arguments in Math.max(), so that means we can’t use Math.max() on an array.

let values = [4, 1, 2, 5, 0];

let highestValue = Math.max(values);

console.log(highestValue); // NaN

If only there was some way to take an array and spread out its individual elements… oh wait!

let values = [4, 1, 2, 5, 0];

let highestValue = Math.max(...values);

console.log(highestValue); // 5

Now that we know about the spread operator, those other array methods seem roundabout by comparison.

Get the Lowest Value of an Array

Easy enough:

let values = [4, 1, 2, 5, 0];

let lowestValue = Math.min(...values);

console.log(lowestValue); // 0

Remove an Index from an Array

We could use Array.splice() for this, but let’s pretend we don’t want to modify the original array.

let arr = [1, 2, 7, 3, 4, 5, 6, 7];

// The erroneous 7 is at index 2:
let i = 2;

let newArray = [...arr.slice(0, i), ...arr.slice(i + 1)];

console.log(newArray); // [1, 2, 3, 4, 5, 6, 7]

Update an Object

You may have a situation where you need to return an object with updated data, but without changing the original object. Take note, React developers: this will often be the case if you use Redux! Luckily, the spread operator works on objects. If we spread two objects into a new object and both objects share a key, the latter object will override the former with its value for that key. The result is a new object with updated data.

let youtubeVideo = {
    title: "PB&J tutorial (GONE WRONG) (POLICE CALLED)",
    likes: 2,
    dislikes: 1000,
    description: "Smash that like button and hit SUBSCRIBE!",
    url: "https://www.youtube.com/watch?v=dQw4w9WgXcQ"
};

let updateData = {
    dislikes: youtubeVideo.dislikes + 1
};

let updatedVideo = {
    ...youtubeVideo, ...updateData
};

console.log(updatedVideo); // same as youtubeVideo, but now with 1001 dislikes

Rest Syntax

Sometimes, three dots together is actually rest syntax, not spread syntax. Here’s the difference: if we use ... on an array or object, it’s spread syntax and we get its individual values. But, if we use ... on individual values, it’s rest syntax and we get an array or object. We can use rest syntax to condense a list of individual function parameters into an array:

function getAverage(...numbers) {
    return numbers.reduce((acc, val) => acc + val) / numbers.length;
}
console.log(getAverage(5, 10, 50, 25, 35)); // 25

Rest Syntax with React

Let’s polish off this article with a hefty example. Let’s say we have some user data we want to render into a list. Any time we render a list in React, we need to give each list item a unique key attribute. We use each user’s id as the key and write something like this:

This is easy enough, but what if we had even more detailed user data? Let’s imagine we also wanted to render our users’ hometown, email address, favorite food, height, weight, worst fear, etc, etc. Suddenly, we find ourselves destructuring and writing out a lot of props for the UserListItem in our map() function.

Luckily, we have an easier way. We’ll destructure the id off each user and then use rest syntax to access the rest of the user’s properties. Then, we’ll spread those properties into our UserListItem component.

Our code still works the same way, and now we have a more flexible and concise map() function.

If we really want to take things all the way, we can use rest syntax within the definition of the UserListItem component:

Hope this helps, and thanks for reading!

Follow me on LinkedIn and GitHub