The Rising Coder - Week 8/13 (Frontend Week 1/3)
Tags: javascript, webdev, beginners, programming
Published: 2022-10-21 19:55:25

Good morning, good afternoon or perhaps good evening and thank you as always for sticking around to read this week's instalment in The Rising Coder. The end of this week 8 marks both the end of the first week in the [Northcoders Bootcamp](https://northcoders.com) and the 2-month milestone!

It's been a really fun journey with my fellow friends in the cohort and the amazing mentors who have been with us since the start. This week has been especially taxing and even had me doubting my own capabilities, so I would like to just re-iterate a few words to my fellow friends in my cohort and potential future bootcampers, and that is you're all doing amazing. 

It takes a lot of grit, determination and dedication to finally get to where you are today. Cast yourself back to the introduction week where you're still learning how to write functions. Or perhaps the *Fundamentals Block* which had you really think about how Higher Order Function Array Methods such as `.map()` and `.filter()` worked under the hood, and look at how naturally you've integrated it in your everyday code? Or heck, even just last week when we've learnt about the Backend and even created our own APIs and hosted it on the internet for everyone to see?

You're all doing a great job and we can make it through the next few weeks into our project phase & graduating, you've got this!

My small pep talk aside, this week I will be diving straight into what we have been up to in our first week of the Front End portion of the [Northcoders Bootcamp](https://northcoders.com). But, before that if you enjoy my weekly blogs, feel free to drop me a follow on [Twitter](https://twitter.com/anipi119), [LinkedIn](https://www.linkedin.com/in/christopher-lam-792b90161/) and [GitHub]((https://github.com/clam119))!

## Deep Dive - What Did We Cover This Week?
I'm not sure how I can *express* how I completely feel about whether I prefer Backend or Frontend Development. (Points if you recognised that pun ). 

This week we covered the following topics of:
* Introduction to the DOM (Document Object Model), Accessing Elements + DOM Manipulation
* Semantic HTML, Accessibility
* Introduction to React, JSX, Functional Components, Props
* Introduction to React Hooks and "State"

However, before diving straight into this week's content, I'd like to just give a few thoughts about how this week went in general. 

When we had finished the Backend project and started our first week in Frontend Development, we would be told that this is around the time that people will often see which type of development that they prefer. 

For the Frontend Development side of the course, we are given complete autonomy for the small-scale applications that we create from start-to-finish as long as we're learning and applying the concepts that were taught during the lecture. 

For the more CSS & visually artistic developers on the course, I believe that this will be the place that you honestly thrive because you will be able to exercise your visually artistic creative side without any restrictions. 

However, this comes at a cost of a "structure" per-se. I can say that I prefer Backend Development because of the rigid structure that we have and how I'm able to instantly receive feedback on whether or not an API's endpoint is working or not and is giving me back information I wanted, without having to worry about any of the styling and CSS that comes with it!

But again, that's just my 2-cents and although it's my first week of the Frontend and using React, perhaps I may come to like it it more!

## Introduction to the DOM & DOM Manipulation 
The DOM or "Document Object Model" is a **tree data structure** that displays which elements within a HTML page is the parent/child of another element. So, for example if you have a `section` in a HTML page, anything that goes inside this section is a "child" of the "section" element.
```html
<section>
  <h1 id="unique-childHeader" class="childHeader"> I am a child of the section element above!</h1>
</section>
```

With this in mind, we are able to essentially write JavaScript that will have access to the elements on an HTML page and manipulate its property. 

One way that we are able to for example manipulate the actual text inside an element using the example above is by getting access to that specific `<h1>` tag and manipulating what's inside of it.
```js
const childHeader = document.getElementById('unique-childHeader');

function deleteInnerText (domElement) {
  domElement.target.innerText = "";
}
<button onclick="deleteInnerText(childHeader)"</button>
```
For this example above, we have assigned the DOM element of the H1 in the previous example and assigned it to a variable called `childHeader`. Then we create a new function called `deleteInnerText` which will take in a DOM element as its parameter and then once it is called, it will specifically target that DOM element's "innerText" (Which is essentially the text inside an element) and then replace it with an empty string, essentially deleting everything within that DOM element. 

Finally, we create a button that upon being clicked, will invoke the `deleteInnerText` function and that will remove that specific DOM element's inner text. 

All-in-all, we spent two-days creating two different small-scale projects that used DOM manipulation so that we could practice these concepts. Me and my partner for the Monday & Tuesday focused on creating a "Who's That Pokémon" game that gave you four options of which Pokémon was hiding behind the silhoutte and would switch to the correct one if you're correct, and lastly a Dungeons & Dragons Themed Character Profile Creator!

## Semantic HTML & Accessibility
Another portion of the first few lectures had drilled into us the idea of "Semantic HTML" and "Accessibility." I will be honest in saying that prior to focusing on this idea of "Semantic HTML" and "Accessibility" I had no idea what it was and why it was needed. 

In essence, "Semantic HTML" refers to using HTML tags that have really specific meaning so that people who use things such as screen readers will have an easier time being able to navigate your website. 

This includes setting up your website so that it has the correct language at the top of the page because people who use screen readers will have the screen reader select that website's language and the audio that's played back to the user will be reflected in the language that's initially setup. 

If you've ever used Google Translate and tried to playback an English sentence from the Japanese speaker's side, you would understand how difficult this could be for those who have difficulties browsing the web. 

So in essence, making sure that you use proper semantic HTML will enable more people to browse your content without having to worry about any ambiguities that may cause them to struggle. If you would like a resource to learn more about semantic HTML and accessibility, then [please click here to learn more!](https://learn-the-web.algonquindesign.ca/topics/html-semantics-cheat-sheet/)

## Introduction to React, JSX, Functional Components & Props
Perhaps the most anticipated section of the Frontend portion of the bootcamp is finally being able to learn about React. I can only speak for myself but I've heard so many great things about React and how it makes a Frontend Developer's life a whole lot easier. 

However, React is definitely not for the faint hearted. Especially if you haven't brushed up on a lot of the modern ES6 JavaScript syntaxes such as Ternary Operators, Higher Order Function Array Methods such as `.filter()`, `.map()`, and `.reduce()`, arrow functions and the `...` spread operator, and much more, so if you aren't completely comfortable with ES6 syntax, then I would highly recommend trying to get familiar with these as these will without a doubt help out a lot down the line!

I apologise for going on a complete ramble before finally explaining, "What is React?" 

*"React is a JavaScript library for building user interfaces and is **declarative** and **component-based**" *.

This is extracted straight from [React's Homepage](https://reactjs.org/) and so what does this mean exactly? It means that React is essentially a tool that makes it a lot easier for Frontend Developers to build UI (User Interfaces) that users will interact with a lot easier. 

Up until now when we have wanted to update a HTML's DOM structure, we would have to traverse the DOM's tree-like structure by using recursion and getting that data which takes up a significant amount of time to do so. Instead, React has a **virtual DOM** which is as it's written in the packaging, a virtual version of the HTML's DOM tree that React uses to get access to the elements in the virtual DOM!

Not only this, beforehand we would have to manually select elements, add eventListeners and then manually assign them to certain elements. This is known as "Imperative Programming" - where we are essentially telling the program to do things in a specific sequence to a T.

However, React is "Declarative" because we just tell React what we want. If we want to have a button that upon being pressed triggers a callback function, we can just go ahead and do that, without all of the hassle like we would do in JavaScript!

And lastly, what exactly does "Component-Based" mean? React is known for building SPA's (Single Page Applications), this means that all of the data will be kept within a single page. Traditional websites that are not SPAs will require you to go to load up a different page when you click something. However, with SPA's built in React, it will **react** to any changes that's happened with the current **state** of the application and **re-render** only specific components based on what has changed. 

### JSX - JavaScript XML
So what is this mysterious sounding syntax called JSX? As the title has already given it away, JSX stands for JavaScript XML. JSX is essentially what allows us to write both HTML and JavaScript into a single file. Take this for example:
```js
const listItems = ['One', 'Two', 'Three', "Four o'clock rock"];

const rockSchedule = (
  <ul>
    {listItems.map((item) => {
      return <li key={item}>{item}</li>;
    })}
  </ul>
);

const root = ReactDOM.createRoot(document.getElementById('root'))
root.render(rockSchedule);
```
This here is an example of JSX. First we have an array called `listItems` and another variable called `rockSchedule` that contains a `<ul>` HTML element (Unordered List) and inside this UL, we use curly braces to specify that we're using JavaScript and its methods. And in this case, we are just going to `map` over the listItems array above, and for each list item in this array, we are going to return an `<li>' that has a "unique key" and the actual item in the array - after that, we just create a `root` variable that is rendered to the HTML page.

## Components - Functional Components vs Class Components
React Components are split up into individual functional components so that they are reusable and easier to deal with. For example, if you had a button on a to-do list not functioning as it should be doing, then you can easily just go into this component and figure out why it doesn't work. 

One big elephant in the room when new React Developers are picking up React for the first time is the concept of "Functional Components" vs "Class Components". When we were first introduced to components, our mentors had just told us that we will only need to focus on functional components because class components are becoming obsolete and will soon become legacy code. 

But, that has gotten me thinking and researching why that is. If you cast yourselves back to the Fundamentals Section of the Northcoders Bootcamp (and my blog entry), we had touched upon the Functional Programming Paradigm and Object Oriented Programming Paradigm. 

A quick recap is that the Functional Programming Paradigm aims to have each individual function do one specific thing only and to not mutate the data that is passed inside of it. Whilst Object Oriented Programming does not mind the mutation of data because it's built upon the encapsulation of data to new each instance instanstiated from a Class, and being able to have methods and properties inherited by new instances. 

Now this brings us to the advice of being told to use Functional Components vs Class Components. From my understanding of these two paradigms, how data is held between the two types of components and seeing the structure of a Class Component in React, this is what I have derived:

Class Components are being discouraged from use because they come pre-packaged with methods (Functions) that are inherited from React, and you aren't completely certain what is being inherited in terms of the properties from Class Components. 

An example of a Class Component is:
```js
class Car extends React.Component {
  render() {
    return <h2>Hi, I am a Car!</h2>;
  }
}
```

The actual functionality of the above example from W3Schools is not important - but what is important is that the `new` class component **`extends`** from `React.Component`, that means by default it will not be clean and already has methods/properties that can be associated with it. 

On the other hand, Functional Components are clean by default. Functional Components are created like a regular function would be and so you would not need to worry about if it has any baggage inside of it, and so you are able to predict how a functional component would behave!

### React State, Props and Hooks 
Oh boy, I will be completely honest with you and say that the concept of React's State and Props had me losing myself yesterday. "State" refers to data or information about a component, and is stored in a "state." This state that is held within a component will be able to be passed down to `child component` that will have access to this data, and is able to change the state of that data.

As React essentially re-renders its components based on changes to a component's state, if a child component that has access to "State" that's passed down by its parent component, then React will see that there's a change in the parent component's state of data and cause that to re-render. 

Therefore, when a parent component re-renders, all of the children to that parent component must be re-rendered.

One method of storing state in functional components with React are "Hooks". React Hooks essentially allows the user to "hook into" a component's state and get access to it. One of the main hooks that we have focused on learning this week is the "useState" hook.

```js
const [todos, setTodos] = useState([
  { id: 1, item: 'Dishes' },
  { id: 2, item: 'Laundry' },
  { id: 13 item: 'Rubbish' },
])
```
This is an extract from the code that me and my partner had wrote for our to-do-list application. The first argument in the `useState` React Hook is the current representation of the data's state, and the second argument of `setTodos` is a function that will be invoked when you wish to update the current representation of the data's state. And lastly, the arguments in the `useState` function itself represents the default information that's stored in the state. In this case, we have by default got three to-do-list items inside!

Next is the idea of passing down state to child components so that they are able to get access to data and their state:

```js
<DisplayTodos todos={todos} />
<AddTodo todos={todos} setTodos={setTodos} />
<DeleteTodo todos={todos} setTodos={setTodos} />
```
This example above has three functional components that are children to this main `to-do` functional component. We want the `DisplayTodos` component to only have access to the current list of todo items, whilst the `AddTodo` and `DeleteTOdo` functions require both access to the current list of todo items and being able to change the state of the todo items. 

In order for us to pass down state as "Props/Properties" to children components, we must specify what they should be called when being passed down, and then have that equal to the state being referenced and passed down.

In this case, we are trying to pass down the `todos` state by doing the following of `<AddTodo todos={todos} />`

Lastly, how do we get access to the state that's passed down as Props to these child components, there's two ways:
1) The first is to have "Props" as the argument to the child component and then access it using dot notation. So for example: `props.todos` 
2) Or the second is through using Object Destructuring. 

Here's an example of both in action in the `DisplayTodos` component that onyl has access to the `todos` state:
```js
//Without Object Destructuring - Pass in as regular props object
const DisplayTodos = (props) => {
    return(<ul>
        {props.todos.map((todo) => <li key={todo.id}> {todo.id}: {todo.item}</li>)}
      </ul>)
}

//Object Destructuring - Destructured the state inside the parameters
const DisplayTodos = ({todos}) => {
    return(<ul>
        {todos.map((todo) => <li key={todo.id}> {todo.id}: {todo.item}</li>)}
      </ul>)
}
```

## Thoughts Going Forward
With that final exerpt on passing down props to child components brings us to the end of this week's blog post! I'm honestly so relieved that it's the weekend and that I've somewhat got a clearer idea of "React State" and how you pass it down to child components, because it was a really difficult hurdle to overcome. I will definitely be trying to relax and spend sometime refining my CSS and React knowledge in preparation for the final two weeks of the Frontend portion of the course!

And so that brings us to the very end, and as always I really appreciate you all for sticking around and tuning in to see how my journey's coding and hopefully learning something along the way, and I hope to see you all this time again next week!

## Socials
Feel free to give me a follow on any of my socials down below!
* [GitHub](https://github.com/clam119)
* [Dev.To](https://dev.to/clam119)
* [LinkedIn](https://www.linkedin.com/in/christopher-lam-792b90161/)