This is my first post since graduating Thinkful, and let me tell you, it has been quite a whirlwind in the interregnum! Aside from beginning my job search, which poses its own trials and tribulations, it is during this period that I encountered my first post-production issues in the projects I created.

While such situations can be a frustrating experience for any developer, I also relish in the success of finding solutions to such problems and the additional experience I gained working more in-depth with several technologies.

..And what better way to really test what you know about a technology than having to maintain a project and fix a few bugs that came out of the wood works!

In this post and the next, I want to discuss two scenarios in which I found myself troubleshooting apps I created several months prior, as it was tampered with by outside forces…

Hello, world! No, this isn’t a total reset…
Although, it kind of feels that way after spending the last portion of my program learning Computer Science principles. I am actually tempted to delve further into those concepts, but I shall refrain from that for now – as I shall deliver on my promise to cover state in React!

Amidst these events in the coding community, I managed to complete the rest of my bootcamp curriculum and, as of April 27th, I am officially a graduate from Thinkful! The last mock interview was a doozy – Linked Lists, Hashmaps… Bubble sort vs. Merge sort… in-order, pre-order, and post-ordering in Binary Search Trees… but I made it, and I am already cracking to get out into the wider world of web development and apply my skills at a new job! Good thing I created the perfect tool to help me with that…

This post will be a continuation of my example React program: Boxes.In my last post, I outlined how to create a basic React component and render it.

That post paid particular attention to how properties (props in React jargon) are passed down to a component in order to give it certain aspects of functionality – and on that note, I made the parallel of a React component being just like a regular Javascript function, with props being an object passed as an argument – each key with a respective value as defined in the component.

In this post, I want to continue the Boxes example by adding more complexity and showcasing how multiple layers of components can pass down props. In this expanded example, we will also see the other style of creating React components: class syntax.

In my previous post, I focused on two basic concepts about React: its use as a Javascript library for building user interfaces and the basic structure through which it accomplishes this task: components.

We also saw how to get our first React app up and running, while paying attention to how this basic starter app utilizes React’s capabilities in order to work its magic communicate with the DOM and render said components.

Part of this process involved noticing the peculiar syntax used to write such apps, known as JSX. We will continue learning about these features in this post.

We will explore one of the two most commonly-used features to take advantage of the way in which components communicate with each other: props.

As promised in my last post, I will take some time to delve into React concepts and procedures in my next few posts – and I will attempt to pay attention to things that I felt were difficult to grasp when I first began learning it.

I want to focus first on the concept of a component. Components are the heart of React. At first, they can seem like something esoteric – especially when you see them implemented with JSX, which can also be startling to newcomers. Nevertheless, two things should help keep us grounded in our journey of React.

This means that React’s purpose is to take existing concepts from Javascript and give us a quicker, more efficient way to do things which are commonly used in web apps. In this way, it is similar to jQuery. So fear not – while we are dealing with strange new syntax and a few new concepts, React actually helps us to do things in a simpler way by converting everything written in a React project back to Javascript. It is particularly helpful to remember this about JSX – although it looks similar to HTML, it is not called HTMLX; the focus is on how it performs Javascript tasks. In the end, its purpose is to provide an easier visual for manipulating things on HTML pages by doing things in Javascript code.

The second thing to remember, which will be a focus of this post, is that React components are simply reusable pieces of code, much like functions. In fact, they are quite often written simply as functions. Creating a component entails giving it its own .js file and everything. This means that it is very modular, making it easier to visualize projects in the long run. While it can be difficult to justify having to flip through so many different files (is this Object-Oriented programming, or what?), I suppose it could be argued that it is a better alternative than scrolling through hundreds or thousands of lines of spaghetti code. But I digress…

2018 is off to a rousing start, as I have jumped back to sharpen my frontend skills by learning React.

Once again, the journey began with a fairly simple concept: a fancy new Javascript library. Been there before (I’m looking at you, jQuery). So what was special about this one? Well, one major difference is that React is much quicker and lighter, as it uses a virtual DOM to update sections of a page independently (these sections are known as components – more on this soon).

After soliciting feedback for my MVP (and a bit of a tussle with Travis CI as I cleaned up my testing regimen), I can now present the new and improved Studyficient!

It feels great to have built something which utilizes client-side and server-side technologies!
The story of this app reads much like learning web development in general – a plot involving learning one skill and quickly finding out that one technology turns into seven more another. For Studyficient, Node, Express, and MongoDB were the three main technologies. Along the way, I encountered the likes of Mongoose, Mocha, Chai, and Passport – as well as a few new services to utilize continuous integration (Travis CI) and deployment (Heroku).

While each of these new technologies is quite distinct from those on the front end, there are certainly parallels which can be drawn from both ‘ends’ of the spectrum. Perhaps the most obvious similarity in the so-called MERN stack is the programming language itself: the N (Node.js) enables Javascript to be compiled and run with server technologies. This gave me an even stronger appreciation for Javascript as a coding language (and C++, as it is the language used to write the V8 engine on which Node runs).

Additionally, the E (Express), the incredibly efficient Node.js framework, helps to construct routes with relative ease – which brings me to another major similarity between frontend and server side: both have a myriad of acronyms by which they describe their modes of operation and common practices (if you’ve read my posts up to this point, you’re probably sensing a theme here…)

Greetings, once again, esteemed reader!
I return to you after a lengthy sojourn into to the server-side aspects of web development!

It was an interesting, exciting – and at times, rather frustrating – endeavor; but thankfully, I have something to show for all of my efforts!

I have come a long way since my last project involving frontend API calls.
My latest project actually involved constructing my own API – complete with a database to store information, including user accounts. This process also entailed establishing authorization with JSON Web Tokens (JWTs) and utilizing Passport.js.

More on the specifics later!
For now, I have another MVP for you to test out!