DEV Community: Tim Tran

Applying for Roles: Coding Assessments... BONUS: How to Deal with Nerves

Tim Tran — Wed, 12 Apr 2023 00:56:57 +0000

It's been almost a month into completing Flatiron School's full stack software engineering bootcamp.

The theme that I can pull away is that as of April 2023, it is tough market out there; however, there are opportunities and you just need to keep looking, networking, and applying, but most importantly keep up with your coding skills (this will payoff in the long run)!

Once you finally get a response for that coveted software/web development job, there is usually an added layer before the interviews in regards to coding exercises, coding tests, etc.

This definitely makes sense because companies don't want to hire the right person and sometimes there is no way around it.

Today let's go ahead and take a look at various formats of coding assessments that I have taken a part in and what it really means!

Coding Assessment #1 - Deliverable

By far my favorite type of assessment, where the company will provide a problem statement to solve in addition to a completion date. They leave it up to you to set up your environment and the technology stack that you are comfortable with.

For lack of better phrasing, the deliverable coding assessment allows for the job seeker to thrive and show off their ability to code and the tools that they use. However, employers will not get a gauge for how job seekers would perform under pressure.

Coding Assessment #2 - Timed Tests

This is where nerves can definitely kick in because I was never a great test taker. The SATs... did not do that amazing... CAT-9 standardize test... better luck next time... Accelerated Reader... yeah...

Growing up I was just a bad test taker; however, I can see how this could be used to filter people that are qualified. Tests in general will show if a person understands the material. But add in a layer of the test being timed, nerves can actually get in the way.

Whether it is having a new environment to navigate like Test Dome or Hacker Rank, etc... you are limited to the technology the employer chooses.

All this to say, you need to choose one main language like C-languages, Java, Python, JavaScript etc. My advice would be to choose one and dive deep because some testing sites won't let you reference documents.

Closing Thoughts

Don't be like me and decide to do all assessments in one day, especially the timed assessments, no matter how easy the sample questions are... Everything gets blended and you don't know if you could use references or not.

You heard this advice one too many times, but take a deep breath and tackle one assessment at a time. Failure is okay because it will prepare you for your next assessment. You just need to get out all the bugs and jitters.

Swapping Databases: SQLite to PostgreSQL for Deployment

Tim Tran — Thu, 23 Mar 2023 23:03:03 +0000

I am officially graduated from Flatiron School coding bootcamp! But the work is never finished ;)

One of my goals was to upgrade my projects by deploying them and a couple of weeks ago I created a documentation on how to deploy your Rails & React app with Render for free! You can check out that article here. This will come in handy later.

I did some searching, but couldn't find exactly what I was looking for, so here is the compilation of deploying a Rails-React application that uses SQLite3.

We are going to dive into converting a SQLite3 database into PostgreSQL to deploy projects that you have created with SQLite3.

Step 1: Swapping out SQLite3 for PG

This first step is based on the assumption that you have postgres installed on your local machine.

First we need to locate our Gemfile, and make the update to the following:

gem "sqlite", "~> 1.4"

gem "pg", "~> 1.1"

then we are going to run the following in the terminal of the directory:

bundle install

Step 2: Update database.yml file

This file will allow us to point to our database within our different levels of environment.

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  database: meal_time_app_development

test:
  <<: *default
  database: meal_time_app_test

production:
  <<: *default
  url: <%= ENV['DATABASE_URL'] %>

(notice that database is name_of_your_app followed by the respective environment)

Step 3: Deleting SQLite3

We are going to look in the db folder and delete the following files development.sqlite3 and test.sqlite3

Step 4: Running Migration

We are now going to run the following in our directory:

rails db:create db:migrate db:reset

Step 5: Follow the Guide to Deploying a React & Rails App.

You are all set! Now you can follow my previous post on deploying a Rails-React app using Render!

Conclusion

Now enjoy the luxury of deploying your projects on Render by converting your SQLite3 database to PostgreSQL.

Deploying a React-Rails App on Render

Tim Tran — Tue, 14 Mar 2023 06:15:50 +0000

I can't believe it! I am almost done with my time at Flatiron School, there is a sense of relief, but at the same time thoughts of what the job search is going to be like has been flooding my mind lately.

What are hiring managers looking for? Do bootcamp graduates have a chance in a market that seems like we are headed into a recession?

Anyways, after consulting with some people in my network that have been in the industry for quite some time it seems as though the best thing to do is to build applications and deploy to build a portfolio of work!

Using Render to Deploy a React-Rails App

Render is an amazing tool that we can use in order to easily deploy applications using React and Rails. Oh did I mention that it is free to use?!

Anyways, for deployment purposes you can sign up for a Render account here! I recommend signing up with your GitHub Account, which will make the process of deploying a lot easier in the future.

A thing to keep in mind for Render is that you will be utilizing PostgreSQL as your database and you can only have one database instance, but there is a work around here that you want to house multiple databases.

Creating a New Database within your Instance

After creating the initial database, right hand corner with Connect and a dropdown, navigate to 'External Connection' and copy and past the PSQL Command into your terminal.

This will launch the PSQL command line, where we can go ahead and create a new database!

Run
CREATE DATABASE meal_time_app_db;

DO NOT FORGET the semicolon... (I forgot this and reached out to their support and they were really nice in asking if I forgot the semicolon)

Now you can check if a new database has been created by running
\l
this should show you all the databases within the instance.

Configuring Your Rails Application

First open the config/database.yml and scroll to the production section and update the code to:

production:
  <<: *default
  url: <%= ENV['DATABASE_URL'] %>

Second, you can open the config/puma.rb file and you can delete everything and paste in the following:

# Puma can serve each request in a thread from an internal thread pool.
# The `threads` method setting takes two numbers: a minimum and maximum.
# Any libraries that use thread pools should be configured to match
# the maximum value specified for Puma. Default is set to 5 threads for minimum
# and maximum; this matches the default thread size of Active Record.
#
max_threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
min_threads_count = ENV.fetch("RAILS_MIN_THREADS") { max_threads_count }
threads min_threads_count, max_threads_count

# Specifies the `worker_timeout` threshold that Puma will use to wait before
# terminating a worker in development environments.
#
worker_timeout 3600 if ENV.fetch("RAILS_ENV", "development") == "development"

# Specifies the `port` that Puma will listen on to receive requests; default is 3000.
#
port ENV.fetch("PORT") { 3000 }

# Specifies the `environment` that Puma will run in.
#
environment ENV.fetch("RAILS_ENV") { "development" }

# Specifies the `pidfile` that Puma will use.
pidfile ENV.fetch("PIDFILE") { "tmp/pids/server.pid" }

# Specifies the number of `workers` to boot in clustered mode.
# Workers are forked web server processes. If using threads and workers together
# the concurrency of the application would be max `threads` * `workers`.
# Workers do not work on JRuby or Windows (both of which do not support
# processes).
#
workers ENV.fetch("WEB_CONCURRENCY") { 4 }

# Use the `preload_app!` method when specifying a `workers` number.
# This directive tells Puma to first boot the application and load code
# before forking the application. This takes advantage of Copy On Write
# process behavior so workers use less memory.
#
preload_app!

# Allow puma to be restarted by `bin/rails restart` command.
plugin :tmp_restart

Third, open the config/environments/production.rb file and find the following line:

config.public_file_server.enabled = ENV["RAILS_SERVE_STATIC_FILES"].present?

update it to the following:

config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present? || ENV['RENDER'].present?

Then, we need to run the following command in the terminal of our app's directory:

bundle lock --add -platform x86_64-linux

Next, inside the bin folder create a file meal-time-build.sh (your-app-name-build.sh)

Within this file you can copy and paste the following:

#!/usr/bin/env bash
# exit on error
set -o errexit

# Add build commands for front end
rm -rf public
npm install --prefix client && npm run build --prefix client
cp -a client/build/. public/

bundle install
bundle exec rake db:migrate
bundle exec rails db:seed

The following script above will be used as the build script later.

But before that we would need to run the following in your app's terminal:

chmod a+x bin/meal-time-build.sh

Now We Need to Configure Our React App for Deployment

The ultimate goal is to create a static site consisting of pre-built HTML, JavaScript and CSS files that can be served by Rails when a user makes a request to the server to view the front end.

So in order create a production version of our React application we will need to run

npm run build --prefix client

Then we need to move this into our public directory, which are the build commands for our front end.

mv client/build/* public

Configuring Rails for Client-Side Routing

Within our React client, we are using client side routing in our development environment; however, for production we need to ensure that we are rendering the HTMl file for our React application since our routes are mainly for the API.

To do this we would need to use namespacing to differentiate the API requests from other requests...

The solution to this issue would be to add a fallback custom route, which job is to render the the HTML file.

i.e.

Rails.application.routes.draw do
    resources :following_ships, only: [:create, :update, :destroy]
    resources :recipes
    resources :shopping_lists
    resources :recipe_ingredients, only: [:create, :update, :destroy]
    resources :ingredients, only: [:create, :update, :destroy]
    get '/users', to: 'users#index'
    get '/user-recipes', to: 'users#user_recipes'
    post '/signup', to: 'users#create'
    get '/me', to: 'users#show'
    post '/login', to: 'sessions#create'
    delete '/logout', to: 'sessions#destroy'
    get '/following-recipes', to: 'following_ships#show_following_recipes'
    post '/follow-user-recipes/', to: 'recipes#follow_user'

  get "*path", to: "fallback#index", constraints: ->(req) { !req.xhr? && req.format.html? }
end

Then we must create a fallback_controller.rb file within app/controllers and create a method that renders the index.html file...

i.e.

class FallbackController < ActionController::Base
    def index
      render file: 'public/index.html'
    end
  end

Creating New Web Service on Render

Within the Render dashboard, we can click the 'New +' button and then navigate to 'Web Service' to begin the process of deploying our React front end with a Rails back end application.

We need to ensure that we set the following configurations:

set the Environment to Ruby
enter the following build command - ./bin/meal-time-build.sh
enter the following for the start command - bundle exec puma -C config/puma.rb
Click 'Advanced' near the bottom of the page...
Add Environment Variable - DATABASE_URL as the environment variable. For the value find the Internal Database URL and paste it in, BUT be sure to change the database name at the end to the database that was created ~/meal_time_app_db.
Add another Environment Variable RAILS_MASTER_KEY, navigate to the config/master.key to copy and paste value into the value field.
Then click 'Create Web Service'

You are done!

Conclusion

After deploying, you can easily update your React app through committing and pushing new code into the repository. GitHub and Render works seamlessly to automatically deploy new code pushes.

Enjoy your application as much as I enjoy creating Meal Time

Under the Hood: Front End React Form Submission Persisting to a Rails Back End

Tim Tran — Sat, 11 Feb 2023 08:00:19 +0000

One of the most important things I have learned so far during my journey into Software Development, is that the ability to talk about your code is a very crucial aspect of being a developer.

At Flatiron School, there are 4 assessments testing students on their knowledge of what they have learned in each phase of the course.

If I were honest, I felt as though I scathed by my first 3 assessments with the usage of my technical vocabulary. I honestly believed that as I dove deeper through the course the ability to use technical terms to explain my code would be a lot smoother.

However, earlier today, it finally caught up to me... I did not pass my Phase 4 assessment...

At first, it was a gut wrench because the thoughts of "is Software Development really for me?", "if I can't pass an assessment, am I good enough to be a developer?"

Well, imposter syndrome hit hard. I sat staring at my computer trying to figure out what went wrong, but it was a little too late to solve the problem.

I came to the realization, that the amount of work and effort I put in over the last few months of staying awake into the early morning hours, adjusting my priorities with friends and family will not be done in vain.

For me, this failure... is an opportunity to learn and quickly move on and improve parts of my skills.

So, in an effort to get better at thoroughly explaining technical concepts and be held accountable by publishing to the world, let's dive into what is happening with a form submission from the client side to the back end.

I will be using my phase 4 project here

Taking a Look at the Review Form Component

Let's break down what happens with the Review Form after it has been submitted... i.e. our handleSubmit function.

function handleSubmit(e){
        e.preventDefault()
        fetch('/reviews', {
            method: "POST",
            headers: {
                "Content-Type": "application/json"
            }, 
            body: JSON.stringify(formData)
        }).then( resp => {
            if(resp.ok){
                resp.json().then(newReview => onCreateReview(newReview))
                onHandleSubmit(false)
            } else{
                resp.json().then( error => setErrors(error.errors))
            }
        })
    }

First and foremost, we have the event handler handleSubmit that takes in the event parameter, which helps us to execute the preventDefault() method.

The preventDefault method allows for us to submit the form without reloading the entire page.

Next we have a fetch post request with the endpoint of '/reviews'. The fetch requests passes the endpoint, method, headers, and body to the back end.

From the Front End to Back End in Steps

Before we breakdown the steps, it is very important to understand that our application is set up with a Model, View Controller framework.

This allows us to build our code in regards to having clearly defined separation of concerns.

The typical analogy of an MVC is a layout of a restaurant...

The model is the chef that never interacts with the patrons(view/front end), and we have the waitstaff(controller) communicating between the two.

The model handles all back end logic from custom methods to associations to validations, etc.

The view is the front end where users can interact with the application to essentially tell the controller what it needs, and the controller relays the information to the model.

Once the model interacts with the database, a response is sent back to the controller and the controller provides the response back to the view.

Now that we have a high-level overview of the MVC framework, let's dive into what is happening under the hood with our fetch post request.

Step 1:

A fetch request is made with the following information: the endpoint, method, header and body in JSON.stringify format.

And this request is sent to the back end. In the case of my project the back end is built using Ruby on Rails.

fetch('/reviews', { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(formData)

Step 2:

The request is passed to the config/routes.rb file to make sure that a route has been created for the method, end point, controller and its respective action.

Within my project I have the following in the routes:

Rails.application.routes.draw do
  resources :reviews #let's take a look here
  resources :restaurants, only: [:index, :show]
  post '/signup', to: 'users#create'
  get '/me', to: 'users#show'
  post '/login', to: 'sessions#create'
  delete '/logout', to: 'sessions#destroy'
  get '/user-reviews', to: 'users#user_reviews'
  get '/users-most-reviews/:id', to: 'users#users_most_reviews'
end

With resources :reviews, we have all 5 actions of index, show, create, update and destroy. In this instance we have a POST request to /reviews that is matched to the create action in the Reviews controller.

To check your routes you can simply type into your terminal:

rails routes

You can learn more about resources method here!

Step 3:

Now the requests travels to the controller and goes through the create action.

def create
        find_user
        review = find_user.reviews.create!(review_params)
        render json: review, status: :created
    end

Our action will not work unless a user has signed into their account. If a user is not logged in they, will not be able to fill out this review form.

So, luckily for us, we are logged in, which means that our code is taking a look at the users table to find the id attribute correlated to the user's sessions user_id hash value.

Step 4a:

Continuing to follow the order of the code stack, we have the logged in user create a review, which means that the request is now sent to the review model to check the associations and validation for creating a new review record in our database.

Step 4b:

But before we can use mass assign the attributes to create the record through this request, we must use strong_params, which is defined within the private method of review_params, to permit the attributes for mass assignment.

def review_params
        params.permit(:headline, :rating, :comment, :restaurant_id, :user_id)
    end

Otherwise, this will not work due to Rails protection against mass assignment vulnerability.

Step 5:

As the record is created in our database, our back end code uses render json to convert the model instance into JSON, and since we have a serializer, Rails implicitly will associate the default UserSerializer to the render, where we can customize the output of the json response being prepared to get sent back to the client via the controller action.

The serializer helps us separate the concerns of our Controller vs. having the controller handle what shouldn't be its responsibility.

Step 6:

Finally, the JSON response is sent back to the front end, where our code utilizes the .json() to parse the JSON into a JavaScript object for us to handle.

In this instance using a callback to update our state in a parent component.

Conclusion

As I work towards improving my ability to communicate effectively as a Software Developer, I that there were value information on how the Client-Server relationship works in terms of a form submission that led to a fetch post request!

Rails Routing - resources vs. resource Methods

Tim Tran — Sun, 08 Jan 2023 07:12:21 +0000

As I am learning more and more about Ruby and Rails, I am beginning unfold CRUD actions and their related behavior in /config/routes.rb file.

What I have gathered so far is that Rails makes it easy to create routes. You can do it by hand (saved for custom non RESTful routes) or automatically with the resource method (or shall I say resources method... more on this later).

However, attention to detail is key as I was stuck on trying to pass an rspec test by automatically creating my 6 RESTful routes.

The Setup

Let's go ahead and set up a new Rails API application (you have Rails installed already)

rails new bird-api --api --minimal

This will create a new Rails API application for us to work through.

Then let's go ahead and create our migration and model through the use of Rails generator:

rails g model Birds name species

This will create our migration of a birds table with columns of name and species in string format.

Then we can go ahead and migrate with:
rails db:migrate

Great!!

Let's go ahead and finish up by generating a controller to handle our routes.

rails g controller birds

Creating Routes By Hand

Let's go ahead and dive into our routes.rb file and create the routes that we want for our birds controller to provide a JSON rendered response.

Rails.application.routes.draw do
  #let's handle our routes manually below
  get 'birds', to: 'birds#index'
  get 'birds/:id', to: 'birds#show'
end

We can do a quick check to see if this works with:
rails routes

Creating the Controller Actions

Now let's quickly set up our controller actions to handle our RESTful routes of index and show.

class BirdsController < ApplicationController
  #let's go ahead and add our controller actions
  def index
    render json: Bird.all, status: :ok
  end

  def show
    bird = Bird.find(params[:id])
    if bird
      render json: bird, status: :ok
    else
      render json: {error: "bird not found"}, status: 
      :not_found
    end
  end
end

Great! We can check to see if this works by adding seed data and seeding our application.

Then we can spin up our server:

rails s

For our RESTful route for /birds, we should see something similar (dependent upon seed data):

And for our RESTful route for /birds/:id, we should see:

Let's Automate Our RESTful Routes With resource

Great! Now let's refactor our code to automate the Routes.

We can do this by going into our config directory and routes.rb file

Rails.application.routes.draw do
  #manual way to create our route
    #get 'birds', to: 'birds#index'
    #get 'birds/:id', to: 'birds#show'
  #automated way to create our routes
    resource :birds, only: [:index, :show]
end

Let's go ahead and check our routes to make sure that we got our two routes by running:
rails routes

Oh no!! We only have one route for our birds controller with the action of show...

Why do we only have one route created?

'resource' Method vs. 'resources' Method

Like I mentioned before... attention to detail is the key here. By not adding an 's' to the end of 'resource' method we only generate the show action for the birds controller in the code above.

Let's take a deeper look into the RESTful routes created if we run just resource :birds instead of the additional `only: [:index, :show]...

We get only 5 RESTful routes that do not make sense at all:

As you can see there are actions for our birds controller for updating and destroying all birds... With RESTful routes conventions, we must target a specific bird to update and destroy.

Now let's go ahead and take a look at if we used the 'resources' method instead:

Rails.application.routes.draw do resources :birds end

We get 6 RESTful Routes that actually makes sense! Two for our /birds and four for individual birds /bird:

Conclusion

We can solve the problem of creating our birds controller action of index and show by simply writing:

resources :birds, only: [:index, :show]

Rails provides easy ways to automate tedious tasks such as creating routes, but it can get tricky at times troubleshooting since you don't necessarily get an outright error that says don't use 'resource', instead use 'resources'.

The devil is in the details, as I struggled to pass my rspec tests all because I left out the 's' in resources. I hope you can learn from my experience of troubleshooting the automation of creating RESTful routes.

TLDR;

Use resources :controllers_name and not resource :controllers_name when automating the creation of RESTful routes.

It's a Read Action, Not a GET Request in Full Stack Development

Tim Tran — Fri, 16 Dec 2022 22:37:36 +0000

Object Oriented programming in Ruby has been the toughest section to grasp so far in my journey of learning how to code, but it has been one of the most rewarding.

Since the last time I have written (Client-Side Routing w/ React Router), it has been a full-circle experience with dabbling in full stack development. Since my journey since September of 2022, I have been developing my skills to build both front end applications and back end applications while leveraging React as the front end library and Sinatra and Active Record as my back end API application.

Throughout this journey, I picked up a magical tip that shows the true power of the back end development, when performing a GET request with a React app.

You can follow along by cloning my Phase 3 Project: Dog Adventures ->
Front End React App
Back End API Server

So let's jump into it as I break down how to write CRUD actions in your controllers file with Sinatra.

What does the 'R' stand for in CRUD?

Before we go answering the question of this header... Let's take a moment to define what CRUD actions are and their corresponding HTTP verbs.

CREATE = "POST"
? = "GET"
Update = "PATCH"
Destroy = "DELETE"

Yes you guessed it! R is Read within CRUD actions and the corresponding HTTP verb is GET.

Let's talk about the differences between the actual CRUD action of 'READ' and the 'GET' HTTP verb and how to use it in correspondence with regards to full stack development.

The GET Fetch Request

The GET fetch request is utilized in both the front end and the back end.

As far as a React application goes the general setup is basically leveraging the useEffect() prop from React:

// App.js

const [dogs, setDogs] = useState([])

useEffect(() => {
  fetch('http://localhost:9292/dogs')
  .then(resp => resp.json())
  .then(data => setDogs(data)
}, [])

In the code above, we are essentially creating a GET fetch request that pulls information from our Back End API Server to set the state of dogs as an array information from the dogs table.

This is pretty basic enough! So let's go ahead and take a look at our application_controller.rb file in the back end application to see how GET fetch request is mapped out.

#application_controller.rb

class ApplicationController < Sinatra::Base
  set :default_content_type, 'application/json'

  get '/dogs' do
    dogs = Dog.all
    dogs.to_json
  end
end

Again, this isn't crazy stuff here, it's pretty basic to where you are mapping the action of the front end's GET request to pull all dogs into state.

Below is what we get when we open up http://localhost:9292/dogs in our browser:

We get a basic JSON file that give us information about dogs in our database that we can use in our Front End application.

The Difference Between Read and GET

The concept of Read is reading our entire back end application that includes our associations.

Within our back end, we have two models ->

Dog
&
Adventure

Each dog has many adventures and each adventure belongs to a dog.

With this in mind, if we were to GET information we could create the same mapped out action for our adventures... But if we scaled and had a big application with a lot of data, running the GET fetch request through our front end multiple times could be costly.

So if we want to Read from both models and run GET once in our Front End and save everything else to state to have access, then how would we do this?

Relationship Associations

Let's take a look at our mapped out GET request for /dogs

#application_controller.rb

class ApplicationController < Sinatra::Base
  set :default_content_type, 'application/json'

  get '/dogs' do
    dogs = Dog.all
    dogs.to_json
  end
end

As you see the .to_json method allows us to use a power feature: include: which will nest a has_many relationship into the hash.

i.e. if we had:

get '/dogs' do
    dogs = Dog.all
    dogs.to_json(include: :adventures)
  end

Then we have access to an array of hashes with all of our dogs and their corresponding adventures nested in their hash.

Let's take a look now at our API:

As you can see, our front end can now have access to all this rich data based on just 1 GET fetch request.

TLDR;

Don't run multiple GET fetch requests in your front end.

Access the power of your back end API by simply associating models in your controllers.

get '/object_tables' do
  objects = Object.all
  objects.to_json(include: :second_tables)
end

A Marketer's Take on Client-Side Routing with React Router

Tim Tran — Mon, 07 Nov 2022 03:39:14 +0000

Currently, I am learning the ins and outs of ReactJS. I have built a minimal viable product using React called TripSave. It is a mock application where you can add a destination, budget, current savings and an inspiring destination image to work towards that goal of saving for that trip.

Anyways, throughout learning React, I have been building Single-Page Applications (SPAs) as practice to get really familiar with syntax and learn how to solve common problems for features such as controlled forms, when to create states, use props, perform CRUD actions, etc. However, one thing that I have noticed while writing React code is that these SPAs do not mimic a "traditional" website in regards to changing the browser's URL when routing to a different portion of the application.

First of All... What is Routing?

Routing is where users are navigated to different pages on a website.

Normally, with web pages built with HTML, CSS and vanilla JavaScript, each page created for the website lives on a server. The website uses server-side routing in order to send a GET fetch request to the server each time users navigate to different pages and this changes the URL path in the browser's URL.

However, with client-side routing, there is only one request sent to the server at the beginning, which pulls in all the data and code necessary to conditionally render the Single-Page-Application based on features within the web application itself. Like mentioned before, this does not change the URL.

React & Routing

By default, there is a lot of code and work around that would go into making client-side routing mimic server-side routing within a React application.

We won't get into those details today...

However, we will be talking about an awesome library that was made specifically to handle routing in React that mimics a server-side approach of changing the URL's path in the browser that users have grown accustomed to in a traditional website, while providing a better user experience.

Pros & Cons of Client-Side Routing

So let's dive right into it...

Pros:

Better user experience with "lightning fast" speed while navigating through different components ("pages")
Developers can create animations in between the load of components allowing users to see that data is loading in a fun way.
As users navigate through the React application, there are no refreshes or reloads of the "pages". Components are rendered quickly and does not need to talk to the server to serve new user interfaces.

Cons:

The initial load time could be a bit longer, since the app is making one request server request to get all data into its components.
Harder to implement web analytics tracking with Single-Page-Applications.

As a marketer since 2016 exploring programming, at the end of the day, we should take into consideration the end users. Therefore in my opinion, when the circumstance is right, having the appearance of lightning fast speed across navigating the website outweighs doing more work to implement web analytics (been there and done that with Google Analytics & Tag Manager).

With that, let's dive into how to create client-side routing for a React application with React Router!

Introducing React Router

React Router is a library created to deliver a better user experience for React applications by allowing users to create Route components that allows users to navigate to "different" portions of the application.

Getting Started

First let's make sure you have the latest version of npm

In terminal you could do the following you can check the version of npm by writing:
npm -v

If you need the latest version you can write this into terminal:
npm install -g npm

Assuming that you have a React project already, go ahead and type the following into terminal in order download React Router version 5 package:
npm install react-router-dom@5

Adding React Router to your React Application.

There are a few components that are important in making client-side routing with React Router with your React application: BrowserRouter, Switch, Route and NavLink(Link).

BrowserRouter Component

The BrowserRouter component allows you to wrap the components you would like to use add routing. Usually this would be the top-level component.

So, let's go ahead and start by importing the BrowserRouter component to your top-level component and wrapping the component around the App component.

import React from 'react'
import {BrowserRouter} from 'react-router-dom'
import Nav from "./Nav"

function App(){
  return(
    <BrowserRouter>
      <h1>Welcome to the App</h1>
      <Nav />
    </BrowserRouter>
  )
}

export default App;

Switch & Route Components

The Switch component makes sure that we only render one Route at a time, while the Route component tells us which component will be rendered on the path that matches the URL.

Route is one of the most important components within React Router and it requires the need for a prop called exact to exactly match the path..

<Route exact path="/">{Home}</Route>

If you do not have the exact prop attached you will not be able to route to other pages because Switch is rendering only one and the Route that matches first, so if you have a path of '/', which is home (normally), without the prop you will not be able to access '/about'.

Let's go ahead and add the components to our code above:

import React from 'react'
import {BrowserRouter, Switch, Route} from 'react-router-dom'
import Nav from './Nav'
import Home from './
import Location from './Location'
import About from './About'

function App(){
  return(
    <BrowserRouter>
      <Nav />
      <Switch>
        <Route exact path="/">{Home}</Route>
        <Route path="/location">{Location}</Route>
        <Route path="/about">{About}</Route>
      </Switch> 
    </BrowserRouter>
  )
}

export default App;

Should I Use the Link or NavLink Component?

The Link and NavLink components act like the anchor tags and href attribute. The difference between Link and NavLink is the whether you want the selected link to be highlighted our not.

If you do, you can use NavLink with the prop of activeClassName to see what is currently showing. Otherwise, they have the same functionality.

So let's go ahead and add the NavLinks to our Nav.

import React from 'react'
import {NavLink} from 'react-router-dom'

function Nav(){
  return(
    <nav>
      <ul>
        <li>
          <NavLink to="/" activeClassName="active">
          Home
          </NavLink>
        </li>
        <li>
          <NavLink to="/location" activeClassName="active">
          Location
          </NavLink>
        </li>
        <li>
          <NavLink to="/about" activeClassName="active">
          About
          </NavLink>
        </li>
      </ul>
    </nav>
  )
}

Conclusion

Again, client-side routing can provide an amazing experience for users navigating through a Single-Page Application with "lightning fast" speeds rendering various components based on routes.

TLDR;

Using BrowserRouter, Switch & Route Components

Use BrowserRouter component to wrap the top-level component where you want to use Routes.

Use Switch and Route components to create paths for components that match what you want to see in browser's URL, while making sure it loads one Route at a time.

import React from 'react'
import {BrowserRouter, Switch, Route} from 'react-router-dom'
import Nav from './Nav'
import Home from './
import Location from './Location'
import About from './About'

function App(){
  return(
    <BrowserRouter>
      <Nav />
      <Switch>
        <Route exact path="/">{Home}</Route>
        <Route path="/location">{Location}</Route>
        <Route path="/about">{About}</Route>
      </Switch> 
    </BrowserRouter>
  )
}

export default App;

Using NavLink or Link Components

Use NavLink or Link to create "anchor tags" with the "to" prop to point where the link takes a user.

import React from 'react'
import {NavLink} from 'react-router-dom'

function Nav(){
  return(
    <nav>
      <ul>
        <li>
          <NavLink to="/" activeClassName="active">
          Home
          </NavLink>
        </li>
        <li>
          <NavLink to="/location" activeClassName="active">
          Location
          </NavLink>
        </li>
        <li>
          <NavLink to="/about" activeClassName="active">
          About
          </NavLink>
        </li>
      </ul>
    </nav>
  )
}

Adding an Event Listener to DOM Manipulated Data Fetch(ed) from a JSON API

Tim Tran — Sun, 16 Oct 2022 04:10:41 +0000

TL;DR:

As a person who has been learning JavaScript for the last 3-4 weeks, here is my take on adding an event listener to a newly created elements through DOM Manipulation from a JSON API fetch:

let databaseURL = '_**url of your json data file**_'
let areaInHTMLToAppend = document.querySelector('_**id or class of areaInHTMLToAppend**_')

function fetchData(){
 fetch(databaseURL)
 .then(resp => resp.json())
 .then(data => {
  appendData(data)
  addingEventListener()
 })
}

function appendData(array){
 array.forEach(data => {
  let fetchedData = document.createElement('div')
  fetchedData.className = 'fetched-data-class'
  fetchedData.innerHTML =`
   _**//HTML manipulation**_
  `
 areaInHTMLToAppend.appendChild(fetchedData)
 })
}

function addingEventListener(){
const newlyCreatedElements = document.querySelectorAll('.fetched-data-class')
newlyCreatedElements.forEach(element => {
 element.addEventListener('**_eventListener_**', _**callback**_)
})
}

function callback() => {
 **_console.log('x')_**
}

fetchData()

Introduction

It was 9:27 PM and I had just gotten done with a zoom session with a technical coach explaining the basis of my code and how I was going to fetch data from the API and manipulate the DOM with this new set of data to assign it.

It was exhilarating! I rushed over to my spouse and told her that I am finally getting it. 3 weeks in and coding is pretty easy once everything clicks.

I thought to myself, I must be a genius let me take a couple of hours and unwind and pick this up again.

But little did I know at the time my thoughts and plan came back to haunt me...

It was now 2:13 AM and I am banging my head against the computer asking why my code isn't working. I totally thought I had the data manipulation correct, but I was missing a crucial piece.

My crucial mistake

I kept getting a TypeError that array.forEach() is not a function...

What did I do wrong? What can I do? My notes that I was taking didn't have this TypeError... I didn't know what to Google and I am taking my array and iterating on it, so why isn't it working!?!? I reached out to the Flatiron School community on slack and it was a humbling experience.

The next day, I learned that I was not accessing my array correctly.

Some wise words of advice if you get TypeError array.forEach() is not a function:

CHECK YOUR ARRAY/OBJECT/DATA you are trying to iterate on...

Are you accessing the right information with dot notation? Are you just pulling in the database as a whole?

console.log() is your friend

In order to answer the pivotal question above, use a console.log

function fetchOngoingRecall(){
    fetch ('https://api.fda.gov/food/enforcement.json?limit=1000')
    .then(resp => resp.json())
    .then(data => {
        console.log(data)
    })
}

Now you can see where the array/object of the data really lies.

In my example, the data retrieved from the .json() method had the arrays in the results.

So how do you access the array?

You Can Use Dot Notation

Do this to iterate on the example above:

function fetchOngoingRecall(){
    fetch ('https://api.fda.gov/food/enforcement.json?limit=1000')
    .then(resp => resp.json())
    .then(data => {
        console.log(data)
        data.results.forEach(product =>{
            console.log(product)
        }
    })
}

This way you can access the array and manipulate the right data.

Why We Are Really Here

Now let's talk about adding adding an event listener to a DOM Manipulated element that was fetch(ed) from the JSON API.

Below is some code that manipulates the data to add into the DOM:

let databaseURL = '_**url of your json data file**_'
let areaInHTMLToAppend = document.querySelector('_**id or class of areaInHTMLToAppend**_')

function fetchData(){
 fetch(databaseURL)
 .then(resp => resp.json())
 .then(data => {
  appendData(data)
 })
}

function appendData(array){
 array.forEach(data => {
  let fetchedData = document.createElement('div')
  fetchedData.className = 'fetched-data-class'
  fetchedData.innerHTML =`
   _**//HTML manipulation**_
  `
 areaInHTMLToAppend.appendChild(fetchedData)
 })
}

In the code above we have created a div for each fetchedData, assigned it the .fetch-data-class and we appended each fetchedData into our designated area to append with the areaInHTMLToAppend variable.

Please note the className assignment is important as we will use it for adding our event listener.

Adding Our Event Listener

Easy steps to add an event listener...

Let's begin by creating a variable that selects all of our new divs with the class name of .fetched-data-class.

function addingEventListener(){
  const newlyCreatedElements = 
  document.querySelectorAll('.fetched-data-class')

It would be very tempting to just add the .addEventListener method to the newly created elements.

If we do we are going to get hit with another TypeError that newlyCreatedElements.addEventListener() is not a function...

Let's go back to my crucial mistake from before.

You cannot just add an event listener to a nodeList or an array-like object, you would have to iterate on it.

So here is the solution:

function addingEventListener(){
  const newlyCreatedElements = 
  document.querySelectorAll('.fetched-data-class')
  newlyCreatedElements.forEach(element => {
    element.addEventListener('**_eventListener_**', _**callback**_)
  })
}

We must use forEach to go through the nodeList and add the event listener to each element and you can listen for any events and create a callback function that you would like.

In Conclusion

I hope this post can help you on your coding journey.

If you are learning on your own, the best advice I can give you is try building a community of people to help you through this journey.

For me, joining Flatiron School's bootcamp helped me to realize that it is great to have a community to learn and go through this journey in becoming a software developer, plus I can get expert guidance and advice from instructors and technical coaches when I'm really stuck!