DEV Community: WizardofHause

TypeScript? But WHY...?

WizardofHause — Fri, 28 Apr 2023 23:58:37 +0000

What is TypeScript?

It seems like it’s on every job post, listed right after to Python. But… what is it? Well, I know that Java is NOT JavaScript, so does that mean that TypeScript is also decidedly NOT JavaScript in an annoyingly misleading way? I was happy to hear that NO! TypeScript is like combining Java AND JavaScript together! I know, sounds lame, and in a way it is, but in a good way…

TypeScript is basically the well, actuallyyyy version of JavaScript. In all the ways that JavaScript is free-spirited and liberal with it’s return values and vague with it’s error messages, TypeScript is the nerdy sibling that knows all the rules to the boardgames and is very eager to correct you when you’re wrong.

The extra cool thing is that all JavaScript is apparently valid TypeScript. The main difference is that in TypeScript, we take the data type assignments -- kinda similar to the syntax used in Java -- and use them to smooth out the adorable and often incorrect guessing game that JavaScript sometimes plays with our data types.

let name = "Frank";
let age = 25;
console.log(name + age) 
//=> "Frank25"

☝️ This is technically valid JS, but wouldn't it be better if it threw an error message instead of doing that pretty much useless concatenation?

let hasOranges = true; 
hasOranges = 5; // <- A boolean to a number? GROSS! WEIRD!

☝️ This is also valid JS, but has the potential to cause some pretty obnoxious problems. That's where TypeScript comes in handy.

TypeScript basically extends JavaScript and is intended to encourage us as developers to be more explicit about the data types that we’re throwing around in our code. That’s where the type in _Type_Script comes from.

For example, you can specify a type by annotating it during variable declaration:

let playerName: string = 'Kevin';

Here playerName is our variable, and we’re telling our program that playerName should only be assigned string values.

By using a : and then the type name (string), we tell Typescript that the variable that we’re initializing should always be a string.

Typescript is basically an add-on, or like a JavaScript expansion if you will, that puts a stronger emphasis on enforcing data type restrictions for variables, so that they cannot be changed.

But...why would we want to do this? JavaScript already works fine, right? Sure, you’re not wrong. Especially if you’re working on a solo project or within a smaller dev team. But when projects need to scale up, and as teams get larger and larger, TypeScript helps to nail down the data types that are expected in the code of the program or application. It also reduces the time and effort we would normally have to take to debug or make updates to our code, when the need inevitably arises. Nerds save the day, once again.

TL;DR

Typescript is really useful for working in teams. There’s less guesswork and it’s more-or-less easier to read.

And that's all for now! This post was intentionally short and sweet, since my last one was such a beast. I'll have more installments on my exploration into TypeScript as I work through the problems HERE. I'm already through the first 4, so stay tuned for more notes!

As always, if you have any questions, comments, or recommendations for edits, feel free to reach out! You can find me on LINKEDIN and I welcome any and all feedback.

Keep fightin' the good fight! ʕ•ᴥ•ʔ

Life After Bootcamp

WizardofHause — Mon, 10 Apr 2023 23:46:57 +0000

So you just graduated bootcamp and you have no idea what to do next, right? I mean, you probably have an idea, but if you’re anything like me, you’ll need more than an idea to keep your head in the game.

After a few months of experimenting and finding out what doesn't work, I found a couple of methods and strategies that do. This list might not be your cuppa, and it certainly isn't exhaustive, but it comes from my personal experience and I love making blog posts about things that can't be found from just a simple Google search.
I'll also give a few tips on what I think should be avoided, because often times knowing what NOT to do is more helpful than vague bullshit about what TO do.

From my experience, there are 5 things that you need to focus on after bootcamp in order to survive in the wild, and they are:

Structure
Motivation
Education
Connection
Patience

Let’s break these down, and I’ll show you what I mean.

Structure

This one might seem like a no-brainer, but I had to get suuuper granular about this. I found out within the first 2 weeks that, first and foremost, I needed a routine. I know there are scores of scheduling apps out there -- I'm partial to good ol' Google Calendar -- but if you already have one that works, then you're a step ahead of where I was, so keep that shit up.

But for me, I needed specificity, I was a lost child in a busy shopping mall and I needed an adult. So I broke out the good ol' pen-and-paper and wrote down everything I was going to do for every hour throughout the day. If I was going to research something, I wrote down specifically what I was going to research and did nothing else. If I was going to take a break, I wrote down specifically what I was going to do during that break and nothing else. If I was going to eat, I wrote down specifically what I was going to eat and nothing else. The way I figured, making decisions takes time, so I wanted to take as much of my brain out of the decisions as I could. If I made all my daily decisions when I was writing my schedule, I wouldn't get overwhelmed by decision fatigue from the little things.

Unfortunately, I found out quickly that this technique wasn't enough, that I needed to get EVEN MORE specific, and I found ultimate clarity from the book The 2-Hour Job Search. Y'all...I really can't recommend this book enough. Instead of regurgitating vague tips from some shitty blog post(!), this book gave me step-by-step action items to focus my job search and prioritize my time effectively. Stop right now, get yourself a copy, and read it. Your whole life will thank you for it and you'll stop wasting time on satisficing strategies.

TIME is the most valuable resource we have, especially as job seekers. So in that regard, I also gotta give a shoutout to the Pomodoro Technique for managing time (this method is particularly effective for those of us with more of a deficit in our attention). Basically you set a timer for 25 minutes and during those 25 minutes you DO A THING. Once the timer is up, you take a break for 5 minutes to DO NOT DO THE THING. I typically spend this break stretching, filling water bottles, getting snacky, or doing small chores. The trick is to stick to the timer as best as you can without turning into your own Drill Sargent. You gotta give yourself grace ALWAYS, which brings me to the next point...

Motivation

This is a big one, and it's potentially the most fragile. When motivation isn't there, the job search just becomes like a form of self-terrorism, and we don't negotiate with terrorists folks. So I try to find motivation anywhere and everywhere, but I find it most useful to have something concrete to draw on when I'm feeling like a frump-a-dump and don't wanna do anything.

Podcasts are usually my first source. Shows like CodeNewbie and Develop Yourself both offer a really great perspective on how to approach the tech industry as a career changer, and are specifically geared toward us recent bootcamp grads and tech n00bz. I have to add a personal disclaimer though; podcasts are great, and they're a fantastic way to get tips and tricks for tackling the job search, but just like watching code tutorials on YouTube, they are by no means a substitution for actually doing the thing yourself. Take that as a word of warning, Future Self. Because I love podcasts.

My second source is social media influencers, which feels lame to admit, but I don't have time for feeling lame if it works. One of my favorites is Mark Thompson, who is the Senior Developer Relations Engineer at Google, so he literally does this for a living. He's energizing and insightful, and I really look forward to his #GoodMorningWithMark motivation posts on LinkedIn.

Another great source is a Twitch Streamer & YouTuber, his name is Michael Paulson, but he's better known as ThePrimeagen. His approach is a little more off-the-cuff and is definitely not for the feint of heart, but I appreciate his blunt honesty and "non-traditional" style. He's also got a fantastic DS&A course on Frontend Masters, which is a great segue to the next point...

Education

This one is a lot more open-ended, and the pool of available resources is a goddamn ocean. From AlgoExpert to Wilco, there is no shortage of platforms to choose from. EdTech is a huge industry (and one that I would be very interested in joining 😅), but no matter what route you choose, you gotta keep those skills sharp. The top three that I've used most-often and continue to go back to are:

Udemy - The whole catalog is great and super expansive, but any class by Colt Steele is a winner in my book. He's got a witty and fresh approach to learning and is great at translating abstract concepts into human-speak. He's got a cat named Blue and he regularly talks shit about himself. He gets it.
BONUS! If you're a Colorado resident, you can get FREE ACCESS to ALL UDEMY COURSES with a Denver Public Library Card.
Scrimba - This is 100% front-end material, but any and every course is awesome because their interface is awesome. You can pause the screencasts and futz with the instructor's code right in your browser. They even have a little in-cast browser that you can test your code on. You can save your code snippets in the screencast, and it’s just a really fabulous platform to get your hands dirty with no environment setup. I went for the full subscription and I use it more often than I use my Crunchyroll account.
edX - This is a great platform for literally hundreds of different courses, but Harvard's CS50 is a great place to start. It's an Intro to Computer Science class and gives you a more in-depth understanding of how all this crazy computer stuff works, altogether. You can sign up for the course to get access to the full materials and labs and stuff, but alternatively all the videos are on YouTube if you just want to passively observe. They also have a Discord channel where you can connect to the full community of CS50 students, which is yet another fabulous segue to the next point...

Connection

With all the tools I've already listed, I still find it reeeeally easy to slip into my head and let the imposter syndrome take hold. With the amount of rejection letters I'm getting and level of information that I should be learning, it's an easy trap to fall into. Fortunately, I found the cure for this in positive human interaction.

I started by integrating this concept slowly. I was applying anywhere and everywhere and getting nothing but rejection emails from robots, which just murdered my motivation. So instead of counting the number of applications I was sending in week-over-week, I started tracking the number of people that I was interacting with and reaching out to. I quickly got comfortable with virtual meetings and awkward informational interviews, and it got easier and easier each time. What's more is that I would get a huge boost in confidence from talking to people, regardless of whether they had a job opportunity for me or not. Before long, I was ready to attend in-person tech events, alone.

As awkward and terrifying as most of them seem at first, I really can't recommend in-person events enough. Attending online events is one thing, but awkwardly stumbling through an introductory conversation with a stranger in-person is very, very rewarding. It helps break down those social anxiety barriers and gets me better acquainted with the awkwardness of talking to strangers. It’s weird, and it’s hard to get used to, but it's had a genuine positive net effect on my networking skills. I still hate it, and it still makes me anxious to go out to random meetups by myself, but each time it gets a little easier and even if the meetup isn’t what I'd hoped, I still put in the effort and got myself out there, and even that alone is progress.

Also, as a bootcamp grad, it really helps me to touch base with my cohort. I really like keeping those contacts fresh because they’re going through the same things that I am, and can offer a helpful dose of perspective.

Keep in mind that another person’s success does not inherently diminish your own! Rather it builds momentum and gives energy to the overall process that helps everyone to grow. And what's that? Another segue!

Patience

The Great Mark Thompson recently had a post where he talks about what he calls The Formula. Essentially, the path to achievement is discipline + grace = success and it has been tremendously helpful for me. I have to stay disciplined and make sure that I'm keeping my eyes on the prize, but if I have an off day, or I miss an opportunity, I have to be able to take that in stride and learn from it. I can't be 100% perfect, 100% of the time, but consistency is much more valuable than perfection.

Job hunting SUCKS! And with all the added distractions and negative news stories and layoffs and recessions and AI bots falling in love with us, it's easy to get overwhelmed and lose hope. But if I remember to take it easy on myself and remember that even if today didn't go so well, I still have tomorrow to learn and grow and move forward towards my goal of becoming a software engineer.

Honestly, I've made plenty of mistakes and I've gotten a lot wrong on my job search so far, but I know that learning happens by making errors. Also, being a beginner in this space is liberating because nobody cares! One of my career coaches told me early on that being overly considerate and excessively gracious doesn't do me any favors. I can fuck everything up on purpose and come out better for it if I keep a growth mindset.
Give. Yourself. Grace.

Do's & Don'ts

Fresh-faced devs are prime targets for predators. I learned early on to watch out for things like places that guarantee job placement, but only after an extended period of minimum-wage "paid training," or that have a weird catch boiled in like a relocation requirement or a percentage cut from your future salary. I won't mention these places by name because I'm certain that some people find success through them, but in my experience, I quickly discovered that if I needed to sign a contract that I have to pay to get out of, then it's not for me.

Long story short, do your research, Google every. single. company. that sends you an offer. Read the reviews, and talk to other devs to get their perspective. Most of the time, if it seems too good to be true, or they're making an unsolicited offer, then there's probably a huge catch.

Finally, do whatever you can to optimize your physical health. Learn from my mistakes. Don't smoke cigarettes. Don't fuck around with your sleep schedule. Don't stay inside all day long. Develop a solid morning routine and stick to it.
Meditate. Drink water. Get sunlight.

Closing Thoughts

Life after bootcamp is tough, and it’s not easy to stay focused after all the structure falls away. Thankfully, there are plenty of resources out there to help you.

Also, here’s a link to Life After Lisa by Bowling for Soup, which was in my head the entire time I was writing this blog post and is apparently turning 23-years-old this year. Shout out to Butch Walker for making all the catchy tunes of my misbegotten youth.

And that's that! Thank you so much for making it this far. I know this is kind of a beefy post, but I've learned a lot in the last few months and I think it's definitely worth sharing.

As always, if you have any questions or recommendations for edits, feel free to reach out. I welcome any and all feedback.

Keep fightin' the good fight! ʕ•ᴥ•ʔ

ERRORS: Bang, Rescue, Repeat.

WizardofHause — Mon, 12 Dec 2022 19:54:12 +0000

So let's assume that we've got our Rails API all set up, our models in place, and everything is working hunky-dory. Except for when it isn't. Our validations are set up, and they definitely work...but how do we know??

Server-Side Validations define how our application communicates with the server and determines what data is returned. So, let's explore how these validations are sent to the controller and displayed on the client-side.

Through our controller actions we can use the method .valid? inside of a conditional if...else statement to determine whether or not our program should render json data, or an error message. We can think of it like this:

Before saving an Active Record object, Rails runs our validations. If these validations produce any errors, Rails does not save the object.
We can also run these validations on our own. valid? triggers our validations and returns true if no errors were found in the object, and false otherwise.
- invalid? is the inverse of valid?, it triggers our validations, returning true if any errors were found in the object, and false otherwise.

The create action is now saying…

if the parameters that the user passed through as input values to book_params are valid and book.valid? evaluates as true
- then render the object as created and persist the data to our database.
else if the parameters did not pass our validation, and book.valid? evaluates as false
- then the application returns all of the error message as an array of strings
- and sets the status code to 422 :unprocessable_entity

The thing that was tough to grasp as a beginner was, using the if...else statement above does not persist our data to the database when a validation fails, but instead returns a nil object, or an empty object that looks like this:

=> #<Book id: nil, title: nil, author: nil, description: nil, page_count: nil, year: nil, created_at: nil, updated_at: nil>

The important thing to identify here is id: nil. Other values may be different, but id: nil tells us that this object did not receive an id when it was created, so its data has not persisted to our database.

…which is confusing. Because even though our instance did in fact fail our validations, we still received what looks like a valid object as a return value. How are you supposed to know if it passed? Check every single id??? Of course not, silly goose. That’s where .create!() comes in to rescue us from nil objects!

.create!() does not create an instance object with nil values, but instead raises an exception, or a return value that includes all our validation error messages, which looks like:

**ActiveRecord::RecordInvalid (Validation failed: Title can't be blank, Author can't be blank, Description can't be blank, Page Count can't be blank, Year can't be blank, Page count is not a number, Year is not a number)**

This return helps us to identify that our instance failed by returning error codes instead of an object that looks like it’s valid, but isn’t.

We can use rescue from within our create controller action to render the exception’s error message as a JSON response

ALTERNATIVELY we can refactor and make this cleaner by using the method rescue_from to give specific instructions to our application for what to do when any exception is raised within our model, for any controller action.

We identify the exception using a specified name (i.e. ActiveRecord::RecordInvalid) and associating a private method called a validation helper and with:

Things to note:

.record is a built-in method, used to retrieve the record which did not validate.
.errors is a built-in method, through which we can drill down into the various details of each error. After Active Record has performed validations, any errors found can be accessed through the errors instance method.
- Returns a collection of errors.
- An object is valid if the returned collection is empty.

Using method-chaining with .record.errors renders our parameter names (:title, :author, ...) and their associated error messages in JSON format. It also sets the status code to 422: :unprocessable_entity

Here, our helper method is render_unprocessable_entity() and takes in a single argument; an object that contains all of the errors that were triggered by the newly created class instance, called an exception.

Client-side routing is different than server-side routing - the customer experience is very very different compared to what the chef is doing - though they are, in an abstract way, still connected, they are not directly dependent on one another.

In order to get our React App to render our error responses, we need to modify the fetch request. For example,

Note: response.ok contains a boolean value stating whether the response was successful (status in the range 200-299) or not.

We have to use Object.entries to create our mappable array in this case because of how our errors data is nested inside of an array, inside of an object, inside of a hash.

Data is nested in a hash with errors listed individually, and their messages as arrays…

{errors: {”title”: [”can’t be blank”]}, {"author": ["can't be blank"]}, ...}
Because of this, if we call Object.entries on our errors, it turns our content into an array of arrays with the key of a particular value in the first index and the error message in a nested array that looks like:

Object.entries(data.errors) --> 

[[title, ["can't be blank"]], [author, ["can't be blank"]], [page_count, ["can't be blank", "is not a number"]]...]

With this nested array, we can call .map on each individual entry and use string interpolation to create an array of errors as strings that we can map through, using their index.

.map(error => `${error[0]}: ${error[1]}`)

errors = ["title: can't be blank", "author: can't be blank", "page_count: can't be blank,is not a number"...]

We can then use a conditional ternary statement within our component to display the error messages, if any exist.
This newly created errors array is then set to state using our setErrors function, which causes our component to re-render
When the component re-renders, it checks the errors state array to see if there’s anything inside of it
If there is, it renders each item in the errors array inside of a <div> element

And that's all there is for errors! From server to client side, hopefully that all makes some kind of sense.

If you have any questions or recommendations for edits, feel free to reach out. I welcome any and all feedback.

Keep fightin' the good fight! ʕ•ᴥ•ʔ

Ruby...Covered in CRUD.

WizardofHause — Mon, 21 Nov 2022 01:10:55 +0000

Now that we’ve made it past the halfway point at Flatiron, I'm starting to understand a lot more about what blogs are and what their basic utility is, especially for beginners.

The point of blogs - at least from my perspective at this point - is to find those diamonds in the rough that hold your hand and spell out the little bits of code you‘re missing, or fire up the right light bulbs in your brain to give you the right ah-HA! moment get your program working. Then you copy-paste what you can, curse at the rest, add it to your bookmarks under Blogs & Stuff.

But feelings come first. And I've gotta say that starting Ruby was tough, and I think that this phase was probably the one that I struggled the most with, but in that same vein, I also learned the most. It’s gratifying and humbling at the same time, and I’m kind of in love with the feeling, but I digress...

For this entry, I’ll assume that the reader is here for the same things I was looking for during Phase 3, that they also have a fair understanding of Ruby, ActiveRecord, Sinatra, and a sprinkle of SQL, and that really they’re just looking for that diamond...or ruby. As such, the following are some helpful snippets that I learned during my back-end brigade.

DATA MIGRATIONS

The order of operations for establishing our migrations and creating our tables starts by creating the migration files. Open the terminal and navigate to the project's directory. Once there, type into the console:

rake db:create_migration create_table_name

NOTE: Our table names should be PLURAL, because they are tables, and they hold many instances of a single thing...they are large, they contain multitudes. For example, my group and I created a mock eCommerce website for our final project, and we needed to create a table of data for our ITEMS, so we ran:

rake db:create_migration create_items

This creates a time-stamped migration files that determine how the tables are set up. Inside of those files, we assign data types and the associated symbol to each 'row' of our table.

For example, for our Items table, we needed a name, price, description, image URL, brand, and category. After creating our migration file, our table looked like this:

We can assign the data types to whatever we like. Other available types are float, decimal, numeric, datetime, time, date, timestamp, binary, primary_key, boolean, bigint, & text, but integer and string seem to be the most common in BeginnerLand. And don't forget to add end at the end of the create_table method! Once our tables are all set up, run:

rake db:migrate

If successful, we should have a new file called schema.rb in the db folder. Next, we needed to establish our relationships so our data can get to know each other and be friends. For our project

These are 'one-to-many' relationships, as in this ONE ITEM, HAS MANY USERS that leave REVIEWS on it. So for the syntax we say

Item has_many :reviews, through: :users

...and, as always, we pay extra special attention to where we put our colons.

This is our 'many-to-many' relationship. Notice how the use of item and user are both SINGULAR here! That makes sense - a review can only be for ONE item and can only be written by ONE user. Once these relationships are set up we can create our SQL tables by running this code in the console:

rake db:migrate

If we have a seed file, that's amazing. If we don't, I somewhat recommend using faker to help out. It's great for making random seeds, but my project group and I ran into some trouble manipulating the output data as beginners, so I'd say it's handy, but only to a certain degree. Once our seeds are filled in, run:

rake db:seed

and that should fill up our SQL tables will some nice juicy data that we can do whatever we like with...well, whatever we know how to do. Which as beginners isn't that much, but WE GOT THIS!

The next step is to set up Sinatra, which you can find much better-explained in their docs HERE.

CREATE, READ, UPDATE, DELETE

So what about CRUD?! Well, I'm not going to give up everything, but it starts with setting up the paths within our application controller. For example:

Those are simple GET requests. We can check our work using an application like Postman, or by running

rake server

in the terminal, and opening up http://localhost:9292 in the browser, followed by whatever our path name is. For example, to route to our item_all path, we would type into the browser:

http://localhost:9292/item_all/

The real money-maker here is the associations within our Object-Oriented-Program. When we pull data using Sinatra ActiveRecord, we can also pull the data that that data is associated with by using include:. So, if we make a route to pull a single item's data, we can also pull the reviews for that item AND the user data for those reviews, like so:

This one route now allows us access to literally every bit of data that we added to our tables. That's...super neat y'all.

Now what does this look like on the front end? Well we made a component that displays the details of an individual item, AS WELL AS all the reviews associated with that item, AS WELL AS all of the user data for whatever user wrote the review. We'll need useState, useEffect and useParams like so:

In our component function we set our item state:

Then we implement useEffect and add a catch if we have any trouble rendering our data for any reason.

Then after a little destructuring, we can add our data to our JSX...

Sweeeeeeeeeeeeeeeeeeet! Rendering data is so cool. It's trending. Or...trendering!

To get the rest of the CRUD, my project group and I ended up setting the list of item reviews as its own separate component, and then each individual review as a card within the component. So we had Details.js which was a parent of ReviewsList.js, which was a parent of ReviewCard.js. This allowed for us to manipulate all the data we were handling without making a huge mess out of the variable names and turning our Details file into callback hell. When in doubt, make another component.

Figuring out the rest was a matter of passing through the correct data using HTTP in our Application_Controller.rb, making the correct handler functions in the correct React Component, and making sure the fetch was doing everything we needed it to do...

For DELETE our application_controller.rb path was:

Our HandlerFunction was:

And the accompanying fetch:

For POST our path was:

The POST HandlerFunction was:

And the POST Fetch was:

And the tricksiest little Hobbitses of them all...the PATCH path looked like:

The HandlerFunction was:

And the Fetch:

... This, of course, isn't the entirety of the code for our React components, but I think it covers more than enough to get the gears turning, especially for my fellow Flatironeers.

And that's it - thanks so much for making it this far! I went lighter on the gifs and heavier on the content this time.

Hopefully this was helpful, especially to my fellow Flatironeers that are having trouble finding a blog where all of this stuff is literally spelled out for you. That blog now exists!

If you have any questions or recommendations for edits, feel free to reach out. I welcome any and all feedback.

Keep fightin' the good fight! ʕ•ᴥ•ʔ

So...what is React?

WizardofHause — Thu, 03 Nov 2022 20:41:33 +0000

Good day and welcome! Thank you for tuning in, let's get right to it...

We just finished up with Phase-2 at Flatiron, rounding out our Front-End adventure with a jaunty sojourn to the land of React.

"React," you say? Why...what's THIS?

And better yet...why should we care? We already know how to use JavaScript, HTML, and CSS - isn't that everything there is to learn?

I mean, aren't ALL websites and applications written in an overly-complicated, nightmare-vortex of JavaScript-callback-Hell from which there is no escape?
Doesn't it take teams of programmers months and months to diagnose a resolve a few lines of buggy code?
Don't developers completely re-write their programs from the ground-up if they need to modify a few elements?
....WHY NOT?!

I hear you. And as logically sound as all of those arguments are, there is actually a reason to care. To put it simply, we use React because we love to RECYCLE!

From React's own website - reactjs.org, "React is a library for building composable user interfaces. It encourages the creation of reusable UI components which present data that changes over time."

So what does that mean for us humans that speak with human words? Well think of it this way; React combines the readability of HTML with the functionality of JavaScript.

HTML is great, but it's also super rigid and difficult to update if we need to. Pages aren't very interactive, and manipulating their layout is a pain.

One way to solve this issue is by rendering HTML elements using JavaScript and DOM manipulation, but...vanilla JavaScript sucks. It's hard to read, and everyone knows it. Vanilla JS has no friends. Like the person that invented the false X on ad windows in game apps.

But since JavaScript has been around for a while, a bunch of smarty-pants people have pretty much already written all the JavaScript rules and stuff that we could ever need to render HTML elements or manipulate the DOM...mostly. I mean, chances are if you need to do a thing in JavaScript, someone else has already figured out how to do that thing.

So why re-invent the wheel? Why not collect all of those JavaScript chunks together into some kind of massive library that we can access and use whenever we want?

That's more-or-less what React helps us to do (even though it's not a library per se, it's actually a framework 🙄). As developers, we use React to call on all those rules and stuff, and make a little hybrid franken-baby chunk of code that looks kiiiiinda like JS and kiiiiiiiinda like HTML.

React also allows us to trim our HTML to just a single file. Neat right? But wait, there's more! We can ALSO take all those persnickety little JavaScript functions and separate them out into their own little containers, where we can control their individual behavior. Then, we can pull all of those containers together into one big group - potentially using some of those containers more than once depending on their functionality - and it's that group of containers that collectively makes up our webpage.

We call these little containers components, which are basically files that hold JavaScript functions and return an HTML/JavaScript syntax mashup called JSX. From reactjs.org, "Components let you split the UI into independent, reusable pieces, and think about each piece in isolation.”

JSX Components combine the markup of HTML with the logic of JavaScript to define an aspect or group of elements within a specific chunk of the user interface on our webpage.

These Components all feed into one another in the same tree-like structure we’ve come to know so well. Much like literally everything else up to this point that we’ve covered, the internal structure resembles a tree, with the top of our dependency tree (typically an index.js file) importing each branched file. Developers. Love. Trees.

React uses index.js to render our components into our HTML file by using the .render method. We use document.getElementById("root") to identify a pre-existing div element in our HTML file with the id="root", and append our JSX components to it. When our program runs, React renders our JSX components as the Children to the Parent div.

The bare-bones structure of index.js looks like this:

import React from "react";
import ReactDOM from "react-dom";
import App from "./components/App";
import "./index.css";

ReactDOM.render(<App />, document.getElementById("root"));

The top-parent component is conventionally named "App.js" and is imported here with the line import App from "./components/App"; Here's an example App component:

import React from "react";
import ExampleComponent from "./ExampleComponent";
import OtherExampleComponent from "./OtherExampleComponent";

function App() {
  return (
    <div className="App">
      <h1>Welcome to React!</h1>
      <p>In React apps, we write JSX - 
it looks like HTML, and uses a lot of HTML syntax
...but it also looks like JavaScript, and uses a lot of JavaScript syntax...
</p>
      <ExampleComponent />
      <OtherExampleComponent />
      <OtherExampleComponent />
    </div>
  );
}

export default App;

Here, App is importing two children components of its own - ExampleComponent and OtherExampleComponent - and renders them as siblings to a p and an h1, all contained within a parent div. We even have OtherExampleComponent rendering twice! WHAAAAT?!

The internal structure of ExampleComponent and OtherExampleComponent is defined within their respective JSX functions, in separate individual files. At the bottom of our App component, we put export default App so that our index.js file is able to import it to use and ultimately render that App component.

This...is a lot. But the basic structure is a quasi-Russian-Doll-esque sort of functionality, where interconnected components can pass information and behavior back and forth as needed. For more on that, check out the React documentation on props.

In a nutshell, React helps us to simplify what's called the boilerplate code. In computer programming, boilerplate code, or simply boilerplate, are sections of code that are repeated in multiple places with little to no variation. When using languages that are considered verbose (overly wordy - cough JAVASCRIPT cough), the programmer must write a lot of boilerplate code to accomplish only minor functionality.

Until React comes along, takes one look at all that absurd boilerplate and dares to ask...

React helps us re-use things that have already been made, and saves us from having to make them ourselves the long way. In the land of the DRY code, the programmer with React is king.

-- ONE FINAL NOTE! --

If you're just starting out, I HIGHLY HIGHLY recommend these videos on Scrimba for learning the fundamentals.

Bob Ziroll is AWESOME and really takes the time to flesh out all the basics of React and how it behaves. Scrimba's videos are HANDS DOWN the best resource I found for learning introductory React stuff. Scrimba allows you to manipulate the instructor's JSX code directly in the video window, and even saves your edits as notes, which I found remarkably helpful for my comprehension.

And that's it - thanks so much for making it this far! If you have any questions or recommendations for edits, feel free to reach out. I welcome any and all feedback.

Keep fightin' the good fight! ʕ•ᴥ•ʔ

How To Approach Your Problems Like An Expert Beginner

WizardofHause — Tue, 11 Oct 2022 02:33:25 +0000

Hello, and welcome, to my very first developer blog post! I'm currently a student at Flatiron School's Software Engineering Bootcamp, and we just finished up the first of five course phases. All things considered, being a beginner coder is equal parts nightmare-horror-story and equal parts...SCRUMTRULESCENT!

I mean, one minute I feel like I'm achieving Kanye-level genius (jeen-yuhs?) when my first 'click' event listener finally works, and the next minute I'm taking my fifth cry-break because the nonsense CSS "rules" I wrote keep breaking the whole webpage (CSS guesses make for CSS messes). Like learning any new skill, it's a rollercoaster of emotion, and I'm definitely along for the ride.

But the most basic thing that really threw sand in my gears right at the beginning, was how do I even get started? All the code-alongs in the world fell short when I was alone and faced with the stark void of an empty VS Code file. But after some helpful insight from my instructors and this blog, I found that the right approach to a code problem can be broken down into 6 (relatively) simple steps:

Understand your problem
Break the problem into manageable bits
Write your process out in human words and leave lots of comments
Use available tools to sample and test stuff you forgot
Slowly fill in the comments with actual code
Simplify and optimize for clarity and dynamic use

Understand your problem

If you think about it, this is really a good rule for life in general, but it also applies pretty well to coding. (In my experience, this almost always boiled down to READ THE README!) In general, you need to know what your problem is asking for, before you start flinging out solutions. Before I started writing, I would pump the brakes and ask myself, "What are the known variables? What things do I need to manipulate or change? What are my desired outputs?" Knowing ALL the specifics of a problem helped me to get closer to finding the solution.

Break the problem into smaller parts

Most coding problems were presented in big, complex, unapproachable formats that were tough to decipher. Breaking down the code into smaller bits helped me to cut through the confusion. Once I divided the problem into smaller, more manageable micro-problems that I actually DID know how to solve, it was that much easier for me to then connect the dots. This also helped me to make my code more dynamic - when I wrote functions that were smaller, and more general in scope, it was easier to implement them as re-usable code throughout the program/application (more on that later).

Write your process out in human words, leave lots of comments

Once I had everything all organized, I would literally write out, in full sentences, exactly what I wanted the code to do, and how I wanted it to do it. These notes weren't necessarily pretty, but were just some human-readable syntax that even non-developers could understand. Putting code into literal words this way helped me to clear the mental cobwebs and make sense out of what I was trying to do. I also found that leaving my outline in place as comments helped me to stay organized while I was putting everything together, AND it ultimately made my code easier for others to read.

Use available tools to sample and test stuff you forgot

If you're unsure if your function will work or if your syntax is correct, you can always test out your code with an online app like Replit, or with the VERY helpful developer tools built into Chrome's Dev Tools. Remove even more of the guess work by tapping in to the multitude of testing tools that are totally free to use. As a beginner, the amount of rules and methods and syntax and little itsy bitsy things you have to remember is absurd. I could not keep track of all of them, and even if I looked them up, I would have trouble remembering exactly how they got implemented. (e.g. Does this method return values or an array of values? Does this method mutate my original data set or make a new one?) Using a REPL to test these little bits of my code was a life-saver, and helped to really layer-in those concepts. I can't even count how many bogus arrays and objects I have made just to check if I was using the right iterator methods. No shame! Tools are there to be used!

Slowly fill in the actual code

Once the problem has been clearly defined and parsed out using the strategies above, I would finally start to write up my code and develop a solution. It's at this point, however, that I personally had to use the most caution and take care to go slowly. It was deceptively easy for me to lose my place while writing up the solution and get frustrated. The good thing is, if the comments and notes from before are organized well, staying on track is a breeze. Just be aware, keeping the end goal in mind is critical during this step - don't lose focus! You're almost there!

Simplify and optimize for clarity and dynamic use

This one is kind of pro-level, but when it's all said-and-done the difference between just okay code and hallelujah-oh-mah-freakin-lawdy code, depends on how dynamic it is, or how re-usable. Ask yourself, can your functions be seamlessly used by other functions as callbacks? Or are they all hyper-specialized, monster-style, mega-functions that only have real use in one particular instance? I know from just my little experience, that the more efficient the solution is, the cleaner and easier the code is to read, and the easier it is to replicate. This one is definitely an on-going, long-term kind of goal to always strive for, but it seems like the sooner you try to implement a more dynamic style into your code, the better time everyone will have.

And that's it! Super simple, right? Well...sort of. Putting these strategies to use now could ultimately help take the tension out of the job interview process down the road (I'm told), and it can definitely help with comprehension while learning new concepts.

Thanks so much for making it this far! If you have any questions or recommendations for edits, feel free to reach out. I welcome any and all feedback.

Keep fightin' the good fight! ʕ•ᴥ•ʔ