React: In Short.
In Module 4 of my Software Engineering Bootcamp at Flatiron School, we spent the majority of our time focusing on learning the ins and outs of React. React is a front-end web framework in Javascript that simplifies manipulating the Document Object Model. The “DOM” as it’s called, is the actual HTML that the user sees in the browser. Backend frameworks, such as Rails, always require a page reload whenever basically anything happens—from logging in to submitting a form. However, if we manipulate the DOM correctly, we can avoid that. An example of this would be infinite scroll, or perhaps adding something to a shopping cart on an online store. Rather than fully reloading and redirecting you, the screen just changes. That’s the magic of front-end!
In my opinion, React is a slightly complicated way to simplify the way we approach manipulating the DOM. Does that make sense? Not really, but nothing in coding is ever very straight forward.
React breaks an application down into Components. It is useful to imagine a Component tree, such as the one below. Let’s imagine this Address Book Application. The largest container on our tree is App. App then holds Contacts, which, below it, holds three more components, Add Contact (a container for a form), Contact List (probably an index page for all Contacts) that holds ContactCard (represents an individual Contact), and a Search Bar (a form that filters the index). As you can see, React breaks its components into a hierarchy. In short, ContactCard lives in ContactList, ContactList lives in Contacts, and Contacts lives in App.
In order to pass information among the components, there are props. Props can only be passed down the component tree. Usually, you would fetch to your data at the highest component on the tree that you may need this information as possible. In this example, it would make sense to fetch at Contacts, and pass down the information in the Address Book to the three children components, and then possibly down to the bottom level of components if needed.
But how would I manipulate this data if it’s all the way up there in Contacts, and I’m using it in ContactCard? Well, this is where callback functions come into play. Let’s say you were editing a contact in ContactCard. You would create the function that manipulates the data in Contacts, pass it down through props to ContactCard, and when it is called upon in ContactCard, pass in the contact’s unique ID in order to search through the array back in Contacts and alter the array. Something like that may look like this:
In this example, I have passed down this method to the individual SushiCard, which takes the ID of the individual sushi. Then, I iterate over the sushi array and add in the SelectedSushi. You may be looking at this and wondering: What is State? That’s a great question!
In React, there are two types of components. Functional Components, which do not hold “state,” and Class Components, which do hold “state.” State is information that can be manipulated only by that component. For example, when you fetch to your database in your component, this would be a class component because you need to store the data in state. You can create as many key value pairs in state as you would like. However, these key values (any kind of data type!) cannot be accessed by other components. This is why you would need a callback function to access this data. In this example, I have in my state an array of sushi, but also an array of eatenSushi. Here, I first find the actual sushi object in question by using the find operator and the ID of the selected sushi to iterate over the sushi array. In the last line of the code, I set the array of eatenSushi to be everything already in eaten sushi, plus the selectedSushi object.
It may seem more complicated than Vanilla JS, as I had learned in Module 3 of bootcamp, but I promise that once you get the hang of it, it is actually extremely useful!
