As this is my first post here in dev.to, I'm using it for different purposes (killing two birds with one stone if you will).
Using markdown for something more than making Readme's, trying out the liquid tags and see how things get embed, apparently not getting emojis to show up, recounting what I've done so far and leaving notes for myself on stuff I learned from React that I probably will forget if I don't use it often enough.

So without further ado let's get those notes going!

The Bootcamp

This last weekend I finished a coding bootcamp in Frontend development particularly using React as the technology for building UI's. The bootcamp was being led by one of the technical managers of the company and it was being assisted by other developers who served as mentors during the whole time.
It started in the first weeks of july so it probably is already a month since then. Most of it was online through live meetings and on Mondays it was required to be present on the site for the talk, which normally was being lead by the tech manager.

Even though the bootcamp was for Frontend development with React, you cannot develop good UI's without having the basics down, so that's what we did first. First week webpage semantics with HTMl and proper styling with CSS. I did my first magazine cover using only HTML & CSS! I never thought that was even possible but I think I pulled it off quite nicely.

Then we move on to make accessible forms in HTML and learn about Aria atributes, I never had any considerations for a11y in my websites before, so that one was a big plus.
Second week it was all 'bout good ol' Javascript, from the very basics all the way to ES6 additions. There was my first big challenge I encountered when I realized my JS skills were quite mediocre. I was used only to make some cool animations and DOM manipulations and that was it (maybe some Ajax and Jquery as well but that's beside the point).

Since I'm a bit perfectionist (although I have improved and no longer get too emotionally attached to the problems I have to solve haha) I spent most of my time at night working on the 'homework' for the topic reviewed.
First thing I did was this calculator which is very simple but it gets the job done.

My goal was fulfilling the requirements with the least amount of code.
That was my personal victory even if it didn't matter much at that stage (although later I realized, that shouldn't always be the end goal)

Solving some katas from codewars also helped dust off the algorithmic skills and practice writing ES6 functions. And then for the final challenge of that week, I made a sliding puzzle with pure vanilla JS no external libraries used.

That really tested out my knowledge to the point that I spent a whole late night scouring the internet and the Mozilla docs to find a simple and elegant way to complete the puzzle functionality.

Now for the third and fourth week it came the Real stuff, it's where React was presented with all it's innovative and shiny new concepts.
You know the drill components, Virtual DOM, JSX, props, state, lifecyle methods, Router and Redux.

Here I did my first React SPA and also gave it a shot to the way too famous ToDo List (because why not). Besides just pumping out code to create things, the emphasis of the mentors was more on writing good code. Clean, semantic and accessible for all the applications created from that point on.

Being focused on performing well in the bootcamp gave me a new perspective on the current trend of frontend development. Instead of going around trying the next flavor-of-the-month framework of Javascript.
What if I could become good at just Javascript in general? What if could choose my tools for development instead of feeling FOMO because I'm not using this new library or framework or technology or whatever.

Enter React

With all this I think I have something to confess. I initially believed React was just a bunch of hype, in fact I actually said it in conversations with some close friends. I was like "yeah another fad that is going to pass soon". Boy was I wrong, this is a totally different way of thinking about UI stuff.

It will take me some time to get used to the way things are handled in React, and to change my OOP & MVC way of thinking about code for more functional stuff, but for now there are some things that made sense to me, made that 'click', that 'ohhh thats why that is for' type of moment.

So let's see here, if we are using components that are supposed to be modular and reusable, how do we handle data? turns out there's two kinds of data. The one that doesn't need to change over time and the one that has to get updated more frequently so that the app runs as expected.

Data that stays the same (static data) is part of the properties of the component, and is called props. Data that is changing and getting updated over time (dynamic data) is what is called state and that's declared once and only updated through the method that is provided for that task setState.

Now since ES6 syntax is pretty much ubiquitous in React there's a lot of arrow functions, let and const, destructuring, promises and most importantly classes. That for me wasn't a hassle (actually quite on the contrary). But is something I saw some other people kinda get lost with and didn't took too well at first.

If I'm making components inside components then there is this relation of Parent and Child, which is not actually due to inheritance Java-style is more like a type of data flow. Parent components can pass down data to Child components as props and then this ones can use it in their functions and do their stuff.

So if the Parent component is the one that holds the logic and the Child components just handle the other details (like interacting and getting input from the user) what if the Child components need access to functions that reside within the parent? turns out the Parent not only can send his state down via props but it can also send functions as well so that the Child can get access to this info.

More React quirks

There's something that I also noticed when creating Components. There's the standard ES6 class that extends from React.Component but there is also a different way of doing this, the one that is with Functional Components.
This Components are basically just normal ES6 functions but with more restrictions and less stuff to write which makes them less prone to bugs.

But then my inner curious asks. Why this are the 2 popular ways of doing it? How can I know when is proper to choose one over the other? is like the how can I know when to use default vs named exports question.
At first I just got my normal answer to know what are the differences between the two, but there's something that made it clear to me.

In one of the talks the tech manager mentioned something I never thought before, state is not just an element used to store changing data, there can be two types of state. State for what the app does (like storing inputs or responding to clicks) and state for how the interface presents its elements (like a toggle or a dropdown).

Which leads us to the discovery of Presentational Components and Container Components. Presentational ones handle all the aspects of the UI and how those elements may change in response to the user interaction and they can even not have any state at all, whereas Container Components are the ones that handle the logic of the application and therefore have state to reflect the changes and pass it down to other components.

Components created with ES6 classes are good candidates for Container Components since they have state, have their context, one needs to access the props with the use of this and also they have the React lifecyle methods. Functional Components on the other hand are better suited for Presentational Components since they are basically just the render method and they don't need anything else (dude just focus on the UI there's nothing else to worry about).

Some people say that for the fact that a Component is Functional is also a Stateless Component, but a Class Component can also be Stateless and on the flip side what if there could be Functional Components that have their own state? Those could be more super saiyan Presentational Components.

Something else that really bugged me at first and then in the day of the final presentation it was brought to my attention, was the use of the this within components. It is normal that when inside a Child Component the way to access its data is by using this.props.whateverdata but if I'll be using it in several different places then the this.props is gonna get repeated a lot.

A neat little trick is by using ES6 destructuring assignment, I can put all the different props in separated variables and instead of doing this.props.userName I can just do userName and it will work the same with the added benefit of cleaner code and less this repetition.

Probably the strangest thing that I had to come to grips with, was binding the this so that my functions inside components would work. This was another thing pointed out to me by one of the mentors, he was like
"why are you binding me the this in the constructor?".

Admittedly I was using 5 different functions in my main component and the constructor looked like I was doing lines as some sort of punishment
(like Bart on the intro of The Simpsons).

I was like "yeah it doesn't look good but that's the only way I know so far" and then in that moment I learned than instead of doing this:

constructor(props){
    super(props);
    this.state = { messages: [] };
    this.sendMessage = this.sendMessage.bind(this);
}

sendMessage(text){
    //My code goes here
}

I can use something that is called Arrow functions in the Class Property and with that my component will change and become this:

constructor(props){
    super(props);
    this.state = { messages: [] };
}

sendMessage = (text) => {
    //My code goes here
}

More clear, succinct and no more lines of binding the this! (I don't wanna be grounded on the chalkboard pls).

So yeah I think that's it, haven't encountered anymore things that could be bugging me (at least for now) and this will certainly help me remember these React gotchas that were kind of alien before.

If you know some other quirks working with components or know other ways I can do things better and more concise, definitely let me know in the comments! I'd love to learn some of these and try them out as well.

In any case, if you read all the way to this point then thank you very much! appreciate your time.