Forem: Nathan A. Hains

How to change React boilerplate icon/text

Nathan A. Hains — Tue, 13 Jul 2021 19:32:11 +0000

I'm gonna show you how we can go from this:

To this:

In just a few simple steps

So,

After hours of sweat, grind and code you've finally deployed your project. You think it's all over, and that the game is won.

That is, until you look up and to the left and see "React app" plastered across your beautiful app.

It's never truly over now is it? Welcome to programming.

In all honesty, recruiters don't want to see that. It gives the impression that you don't refine all the edges, and may very well be the deciding factor in moving on to the next applicant. Good news is that if you're reading this, that isn't going to be you.

How to Change the boilerplate display

1. Do not deploy until the end of this blog

There are some default mechanisms in place that, in the case of deploying before finishing, will reset all the progress you've made. Heed my warning, you will be very mad.

2. Take a look at the folders on the right.

Chances are, if you're seeing boilerplate, you've ran create-react-app some way or another. You should see two folders. Public and Build. We will focus on 4 of the same files within each: manifest.json, index.html, favicon.io and logo192.png.

3. Set up your replacement pictures

You're gonna need two files. The first, a .io (favicon icon) file, and the second, a .png file. The first is gonna be for web browsers, the second for mobile devices like you saw in the beginning of this blog.

I recommend using https://favicon.io/favicon-converter/ for your .io file. It is free and easily accessible. Zero hassle.

Once you've got them ready to use, load 'em up into build and public.

4. Replacement time

Go ahead and delete favicon.io and logo192.png, we won't be needing them anymore.

Next, next head into one of the manifest.json files.

They are the exact same and should look a little like this:


{
  "short_name": "React App",
  "name": "Create React App Sample",
  "icons": [
    {
      "src": "favicon.ico",
      "sizes": "64x64 32x32 24x24 16x16",
      "type": "image/x-icon"
    },
    {
      "src": "logo192.png",
      "type": "image/png",
      "sizes": "192x192"
    },
    {
      "src": "logo512.png",
      "type": "image/png",
      "sizes": "512x512"
    }
  ],
  "start_url": ".",
  "display": "standalone",
  "theme_color": "#000000",
  "background_color": "#ffffff"
}

Edit your short_name, name and src lines to your respective file names.

Finally, head into index.html and find/replace these lines:

<link rel="icon" href="%PUBLIC_URL%/favicon.ico" />

<link rel="apple-touch-icon" href="%PUBLIC_URL%/logo192.png" />

<title>React App</title>

Run deploy and there you have it!

Look how nice. Go ahead and pat yourself on the back, you're now a more robust programmer 😄

If you liked the article, consider giving me a follow!
I'm always updating the webiverse with more how-to content.

Also, connect with me on Linkedin! https://www.linkedin.com/in/nathanhains/
Always up to meet new people.

Aside from that, I hope you have an excellent day!!!

Animate in style with Framer Motion

Nathan A. Hains — Tue, 06 Jul 2021 20:47:44 +0000

If you're thinking:

"Wow, that looks complicated!"

or

"Wow, you've got time on your hands."

Then allow me to introduce Framer-Motion

As per https://www.framer.com,

A production-ready motion library for React. Utilize the power behind Framer, the best prototyping tool for teams. Proudly open source.

To put it simply,

you can use framer-motion to create elegant animations like the one listed above in as little no time.

To start

run the following command within your React application:

npm install framer-motion

Once you've got that set up you're good to go.

What specifically you want to animate is up to your choice. Here I will show you an example that's easy to understand.

Regardless of what you choose to animate, the options are endless.

Let's begin with a simple example.

Let's say you have a div within a component like so:

<div>
   <h2>Header!</h2>
</div>

And you want to animate that header to come from the right and to fade in.

First

Import both AnimatePresence and motion from framer-motion

import {AnimatePresence, motion} from "framer-motion"

This will allow you to add "motion." to whatever element you choose give animated capabilities.

Then

Add the code to your render

<AnimatedPresence>
   <motion.div>
      <h2>Header!</h2>
   </motion.div>
</AnimatedPresence>

Finally

Framer-motion gives a ton of options to fiddle around with. In this examples, we will only be using opacity and x-coordinates

<AnimatedPresence>
   <motion.div 
       initial={{x: 100, opacity: 0}} 
       animate={{x: 0, opacity: 1}} 
       exit={{opacity:0 }}
       >
      <h2>Header!</h2>
   </motion.div>
</AnimatedPresence>

Voila

You now have a basic understanding of how to implement framer-motion into your application with smooth animations!

For details on the transition from the beginning

Check out this how-to guide by CoderOne!

Reducer, Store, ACTION!

Nathan A. Hains — Sat, 26 Jun 2021 03:35:16 +0000

React

can be a confusing, yet amazing learning experience for the willing. It's all too easy to fall victim to the interwoven tunnels of passing down state from component to component. But what if I told you there was something that could help shed some light through those code-ful tunnels?

Enter Redux. An open-source JavaScript library created by Dan Abramov and Andrew Clark centered around managing state. But you aren't here for the back story, right? Right. Let's get into the why aspect.

Let's say you're like me. Or, me a month ago. You want to create a new React application to post up some workouts for your bootcamp finale. Pretty simple sounding right? Until you map out the schematics of passing down state 101 times without the Dalmatians. Pretty tedious if you ask me. The way redux saves the day in this scenario is by holding state in one place. That's right, one. In bold so you know that's a game-changer.

To put this into perspective, take a look at how we'd begin this process of introducing redux.

The first thing you're gonna have to think about, is what your future self will be thinking about. Not to get too inception-y, but you'll need to be able to call upon something to get what you want. This will be that something. This is what's called the reducer. Here is where you'll dispatch(keyword) specific tasks & items. So, in this example I'm imagining that I'll be dispatching an action(another keyword) of adding a workout. Take a moment and let that big-brain wonder where we'd go next.

If you guessed back to the future, you'd be right! Now you're in the future and you've got your reducer with no action to dispatch. As you might and should have guessed by now, this item is your action. This establishes a communication line between your reducer and wherever or whatever you wish to call upon your action to dispatch. But what's the point in all of this build up? Where's the climax?
Will the big bad React-patience-snapping-Gauntlet ever be defeated?

Well,

TUNE IN NEXT TI--

Just kidding.

Introducing Store! The one and only, all-encompassing, holy grail of state management! That is, if you can look beyond the distracting left in cursor-highlighting. Nevertheless, you'll see we've called our reducer for a nice family reunion. This is great because now we can use all sorts of goodies such as connect to manipulate wherever we please! To an extent. Let's take a look at two examples in this project.

If you take a look at the top and bottom there, you might be reminiscing of an abandoned Xbox device from long ago. Using Connect, we can directly access stored state without having to pass down from component to component. In this example, we are using mapStateToProps. As the name implies... --On second thought, I don't even think I have to finish the sentence. But I will anyway.-- ...this maps the State to your props which you can then use however you please! What a load off the hunched programming back, am I right?

In this second example, we see a familiar connect being the good sport it is. Instead of mapping the state to our props since it's unneeded here, we set null and use the second argument to call over a reduxified version of one of our actions! Here we're essentially saying "hey redux, do what you do best and send this workout to my action, to send this workout to my reducer, to store this workout in my store."

Thanks, redux.

Well, if that distracting highlighting-cursor didn't scare you away by now, you've made it to the end! Congrats! You may now be a little bit more prepared than you were 5 minutes ago!! But in all seriousness redux can be a life saver depending on the type of programmer you are. I may seem a little bit biased here, but there are tons of different ways to get to your finish line. Redux can be a great tool for a certain path, but passing state along down the rabbit hole may have it's own benefits. Who really knows? My advice: play around and see what works best for you. With all that being said, I hope you enjoyed the read and have yourself a happy rest of your day.

-Nathan

Phase 4

Nathan A. Hains — Thu, 27 May 2021 04:40:18 +0000

Phase 4 has come to an end and with it, a new project week begins!! Or has begun.. & finished. But nonetheless new insights have come my way through this journey and I would love nothing better than to share my newfound knowledge with my cherished readers!

Javascript is tough. There's no real way around it, unless maybe you started with javascript but even then the language is a real mind bender!! The biggest obstacle for me in designing my phase 4 project was where to go, what do do & most importantly HOW TO MANAGE JAVASCRIPT'S SYNCHRONOUS EMBODIMENT.

Before that, I'd love to share this beautiful mantra I learned from a wonderful Flatiron instructor named Ayana Cotton. "When some event happens, I want to make what kind of fetch and then manipulate the Dom in what way?" This helped center my brain onto a one way track from start to finish. Simply add an event listener to the element you wish to expand on, use fetch to manipulate the backend once that event is listened to, and finally, change the dom to reflect that change in the frontend. Easy to remember right?

Now back to synchronous. What this means is that Javascript performs one operation one at a time. But some things take a while.. such as manipulating a backend server. Since you'd rather not have the rest of your application wait one or many specific operations, we use these things called promises. Promises are just like they are in day to day life where you basically tell javascript that we promise to perform the task so everything else can load without a worry. Even in the event that a promise fails, we use catches to catch that failure and do something with it.

Fetch requests make this process a lot easier where the promise syntax is combined into a simple word "fetch" that takes in the url you wish to make the fetch request to. What you wish to do with that returned information only once it is returned is chained on through ".then"s.

To visualize this, here is a fetch request from my application called "iRemind."

 getLists(){
        fetch(this.baseListURL)
        .then(response => response.json())
        .then(lists => {
            lists.data.forEach(list => {
                let newList = new List(list, list.attributes)
                document.querySelector("#list-container").innerHTML += newList.renderList()
            })
            reminderForm.addCreateReminderForm()
        })
    }

Here, I wanted to get all the lists that are stored within my rails api backend.

fetch(this.baseListURL)

this is the fetch request being made where baseListURL is the url to my backend stored in a global constant elsewhere.

.then(response => response.json())

Here is the chained on task once that fetch completed where I tell my program to turn that response to json!

.then(lists => {
            lists.data.forEach(list => {
                let newList = new List(list, list.attributes)
                document.querySelector("#list-container").innerHTML += newList.renderList()
            })
            reminderForm.addCreateReminderForm()
        })
    }

The rest of the code within the final then simply names the jsonified data as lists, which is what I wanted to then manipulate the data as I pleased.

Fetch requests along with the mantra "When some event happens, I want to make what kind of fetch and then manipulate the Dom in what way?" were INTEGRAL to my understanding & really made connecting the dots a lot easier than they would have otherwise. Hopefully this cleared some of the gaps for you too! Until next time.

Phase 3 Finale

Nathan A. Hains — Fri, 30 Apr 2021 22:18:22 +0000

Today marks the final day to Flatiron's Phase 3. The main topic for Phase 3 was the introduction of Ruby on Rails. This was the most challenging Phase thus far but not without its rewards. One such reward came disguised as a valuable piece of knowledge. This was on how to create groups for an application, dividing a single model into two different usages.

I wanted my users to be able to create a group(faction) that other users could join. Leader vs Joiner. The problem that stumped me was on how to implement leaders & joiners into a single model, Users in my case. To put this into perspective: a faction belongs to a leader, while also having many joiners. Both leaders and joiners can have many factions. theodinproject.com was a wonderful resource on how to implement this idea.

You will have three tables set up like so:

class CivilianFactionRequest < ApplicationRecord
    belongs_to :requestor, class_name: "Civilian"
    belongs_to :faction_request, class_name: "CivilianFaction"
end

class CivilianFaction < ApplicationRecord
    belongs_to :owner, :class_name => "Civilian"
    has_many :civilian_faction_requests, foreign_key: :faction_request_id
    has_many :requestors, through: :civilian_faction_requests, source: :requestor
end

class Civilian < ApplicationRecord
    has_many :civilian_faction_requests, foreign_key: :requestor_id
    has_many :civilian_factions, :class_name => "CivilianFaction", :foreign_key => "owner_id"
    has_many :faction_requests, through: :civilian_faction_requests
end

Now to break this down. The CivilianFactionRequest is the join table that will hold the information from the other two tables. This belongs to the specific faction that a user is requesting to join, as well as the user themself.

The lone Faction model is where things start to get tricky. The first line sets the owner upon creation. The second is saying it will have many requests under the specific faction request id. The third is saying the faction will have many requestors(joiners).

The first line describes that the Civilian model(user) will have many faction requests, through the join table, under the requestors id(once they send their request). The second line tells us that the user will have many factions under the owner id. The third tells us that we will have many faction requests as the owner through the join table.

To match these relationships, the migrations will also have a part to play. The civilian migration will be whatever you determine. The important tables are the factions, and the faction_requests(join table)

Civilian_factions:

create_table "civilian_factions", force: :cascade do |t|
    t.string "name"
    t.integer "owner_id"
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
  end

Civilian Faction Requests:

create_table "civilian_faction_requests", force: :cascade do |t|
    t.integer "faction_request_id"
    t.integer "requestor_id"
    t.boolean "accepted", default: false
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
  end

As mentioned previously, the faction will belong to the owner. Through the join table, the faction will have many joiners. To do this, the join table has to take in the faction id as well as the joiner id.

Once this is set up, active record gives you full capabilities to call on chained methods such as

CivilianFaction.first.requestors

Which will query the faction table for the first faction's requestors. Not to mention the ability to create groups as a leader, and join them as joiners! A tough concept to tackle but super useful in the long run.

Thank you for taking the time to read!

Phase 2

Nathan A. Hains — Thu, 25 Mar 2021 17:51:45 +0000

Today marks the 4th day into Project Week for Phase 2 at Flatiron's Software Engineering Bootcamp.

Throughout the second phase, we were tasked with learning loads of new information. Of the many, we had learned both the basics & the depths of sql, active record, Sinatra, css, and html. This was definitely a step up from the last phase where we had learned strictly ruby object orientation principles. There were plenty of challenges for sure on my end but not without their eventual completion.

The major challenge for this phase was learning how to implement CRUD and RESTful Routing. Basically what CRUD stands for is Create, Read, Update, and Delete and is used for persisting storage. If I were to plan out a website with a database that users can react with, I would implement CRUD to manipulate the data. Now as for the routes that allow users to access these CRUD methods is through RESTful routing. What it means to be RESTful is to follow the naming pattern of consistency across route name and paths that reflect what they are doing.

Now, as a beginner, that is difficult to read in and of its own. Implementing this into a full on project is another story. But this is where the real fun is. For me, diving into this project was like diving into a pool without knowing HOW to swim. Sure I know the mechanics of swimming, and I've seen people swim before plenty of times. But as for the actual SWIMMING aspect, I'm dead weight. Same went for this project. Although it was a real struggle, removing the training wheels that come with labs is where I really cement the knowledge I've been collecting throughout the phase.

To better demonstrate this, I'd like to show a little bit of my code. A feature I had wanted to implement is for user's to log in. To do this we start with a GET request to '/login' which will be in the form of a link on the home page. That looks a little like this:

 get '/login' do
        erb :'/users/login'
    end

Now, what this is doing is saying, hey, show me the login page which my program is designed to read this and provide the that login page through an erb file. Within that erb file I had to figure out how to display to the user sections for a user to input their credentials that is both productive and nice looking. In comes bootstrap. Bootstrap is basically a seamless way to add features to your website while doing all the work for you. This may sound lazy to some but an ocean of possibilities for beginners. Bootstrap not only allows you to get predesigned features but to manipulate your own. How I designed my login page is through the following:

 <div class="text-center">
    <form style="max-width:480px;margin:auto" action="/login" method="post">

        <img class="mt-4 mb-4" src="images/this.jpeg" height="100" alt="logo">
        <h1 class="h3 mb-3 font weight normal">Please sign in</h1>

    <input type="text" name="username" class="form-control" placeholder="Username" required autofocus>
    <input type="password" name="password" placeholder="Password" class="form-control">
    <div class="mt-3">
    <button class="btn btn-lg btn-secondary">Sign In</button>
    </div>
    </form>
    </div>

Which greatly benefits the user experience when put into action. From there the user's information is sent to the '/login' action through the method post which identifies the user and brings them to their profile page. Pretty cool, right?

By the end of yesterday, which is when I had completed the first set of features I had hoped to create for this project, I can finally say I AM a Software Engineer. The fact that I was set out on my own and came back with a fully-functioning website, albeit still in its early stages, is indescribable. With 3 more phases to go, I am becoming more and more confident with my abilities to adapt to and implement any obstacle/knowledge that comes my way.

Here's to another successful phase and to the ever-approaching finish line. Cheers.

Week 4

Nathan A. Hains — Wed, 24 Feb 2021 04:02:12 +0000

Alright!

So, as the title suggests I, along with my fellow cohort-mates, have successfully completed week 3 and pushing into week 4. This is the end of our first phase where we push our knowledge over the course of the phase to our absolute limits! This has been a challenge for sure but a rewarding one at that. As much as I've stared at the screen, lost for thoughts on where to go next, I've equally felt the rush of conquering my hurdles.

Week 4 is where it all comes together. We were presented with the task of creating our own command line interface gem! At first read, my nerves jumped for sure. At second read, it was grind time.

I heard that project week was going to be tough. Many times. So much, that I wasted no time and began doing my research so that I could be as prepared as possible when it came time. Suffice to say, when it came time, I was confident in my abilities to get all the requirements settled.

My project idea was centered around the aid of my fellow cohort-mates. I wanted to create something that could help relieve some of the stress & anxieties that people were facing as they stamped through the lines of code. Thus, "Inspirational Stress Reliever" was born! The user is greeted, asked if they're feeling stressed, and provided as many inspirational quotes as they want! One of the requirements was to make sure the program went one level deep. My idea for this was at the end of attaining their quotes, the user is read a list of their quotes and provided an option of selecting from their list, the author of any provided quote. That's just about my program's cli in a nutshell. Sounds simple enough. Until you check under the hood.

My project went through many, many changes. This is due to both the creative freedom Flatiron offers for this project, and the requirements. The overlaying goal is to make your program object oriented. This means you are CREATING OBJECTS and working WITH OBJECTS!!!!!! Note, this is not me screaming at you, dear reader, but to my past self. The first version of my program had grabbed information from my api(which grabs the random quotes as hashes containing the attributes of the quote) straight from the cli. Big no-no. The idea of object oriented programs is to separate your concerns, which means you don't have just one class doing everything but separate that do, separate things. Excuse the layman terminology. After I got that down though, was where the real fun began.

One change I want to mention was centered around user interactivity. At first, the user was presented with choices like so:

print "Enter 1 for 'yes', 2 for 'no'
input.gets.strip

Yikes.

Although not the worst way to present text for user input, it is definitely not the prettiest. My solution for this came from my wonderful cohort leader, Laura Berge. She had suggested I look into the ttyprompt gem to make my cli more user friendly. Looking through, I had agreed and proceeded to download the gem and work through implementing that gem. And so, my program went from that super robotic formation into:

prompt_1 = TTY::Prompt.new
            puts ""
            prompt_1.yes?("> Would you like to know any of the authors?")

Although you may not be able to tell, this makes a world of difference. Now instead of entering 1 or 2, from which I would have went into 2 other methods for wrong input and to return usable options, the user can enter y/n (which is displayed next to any question) or yes/no. On top of that, if the user inputs anything else it automatically produces an output for invalid input AND turns the user choice green. This was a game changer. My program is a lot nicer to look at and I'm a lot more confident in presenting to others.

This is just another stepping stone in the field of becoming a Software Engineer. I've learned a lot in so little time and I couldn't be more grateful. Words can't describe how excited I am to see where the next hurdle takes me.

Until then,

Nathan Hains

First Mile at Flatiron School for Software Engineering

Nathan A. Hains — Mon, 01 Feb 2021 17:33:50 +0000

Hi!

My name is Nathan Hains. I am currently 22 years old looking to further progress my journey as a Software Engineer at Flatiron School. I began this journey at Suffolk County Community College through an Intro to Java Class. I will admit my introduction into the programming world was difficult. That challenge, however, is what really pushed me to further my knowledge. I looked up to my professor and his skillset. I wanted to learn what it took to get to where they were. From there I was decided on where to focus my attention for the years to come.

After graduating from SCCC I had gotten accepted into Farmingdale State College with a major in Computer Programming/ Information Systems for my BA. I had completed 2 semesters when I heard about the world of Coding Bootcamps. I was/am still very much in full force for attaining my bachelors at Farmingdale. But I decided to first focus my efforts on completing a Coding Bootcamp. I had heard great reviews from various bootcamp alumni. Flatiron in specific had caught my eye from the start. The passion I saw in these Flatiron graduates was inspiring. Regular people, like me, had changed their lives for the better! I saw how rewarding the challenge of completion can be and focused my efforts on how I could be one of these people.

Now, on February 1st, 2021, I can proudly say I am beginning my First Mile with Flatiron School as a Software Engineer. I have met with my Cohorts and saw the happy faces of my fellow students. It is super exciting to see where the next 5 month will take us all. I am ready for this challenge. I will update my journey in hopes to serve as a source of inspiration as others have been for me. See everyone in the next milestone! Wish me luck!

Nathan Hains,
Future Software Engineer