Forem: Nathan Chung

How to query an API for your React Project!

Nathan Chung — Fri, 09 Oct 2020 18:24:07 +0000

This post requires previous knowledge/understanding of React and JS

For my capstone project, I noticed that there aren't many user forums giving access to Stock Market data. After spending some time going through stock market documentation, I now understand why.

What is an API?

API stands for Application Programming Interface. Many companies build API's for users to use and create their own awesome applications. In our case, we want to look into the stocks and a company like MarketStack for our project.

First, we'll be using Insomnia to fetch market data and MarketStack as our API. Luckily, most API's return JSON readable format which we'll make it easy for us to use!

Insomnia allows you to test and query API's without needing to have everything built out. We'll be using Insomnia to test GET requests from MarketStack. Make sure to install Insomnia Core

MarketStack provides free real-time and historical stock market data with thousands of tickers via REST API in JSON format, access to tons of exchanges, and you get 1000 queries a month. (10,000 for $10.00)

Head on over to https://marketstack.com/ and click the following.

Once you're there, you'll be directed to sign up and register and you'll then have your own API key.

Save it and write it down and make sure you don't expose it publicly.

If you head over to MarketStack's documentation, there is a ton of data; end-of-day data, intraday data, stock exchanges, currencies, and everything you can think of... financially.

The basic way you'll write a query for Apple like this:

http://api.marketstack.com/v1/eod?access_key=YOURAPIKEY&symbols=AAPL

Using Insomnia

Now let's take that to Insomnia.

In this program, you have a bunch of ways to test API's, send data to your own backend, and more! For our example, we'll send a fetch request to get information on Apple.

Take the same query from above and paste it into Insomnia. Make sure your options are set to 'GET'. You'll receive a 200 OK message along with all your stock data!

Now that we have our data, let's see an example of its usage within a React project.

Hiding your API key

Create a .env file within your React at the highest level. This is important because in most cases, API keys are private and for you/your group. Exposing your API key could literally be very costly.

then in .gitignore be sure to add .env to prevent uploading to Github!

Now in your .env, set your API key by starting off with
REACT_APP_MARKETSTACK_API_KEY='YOUR_API_KEY'

Replace the single quotes with your own API key. Make sure to include REACT_APP, otherwise it won't work.

run npm start to spin up your server and let's check if everything worked correctly.

Testing Fetch Requests

Now to ensure that it's working, go to a component and type the following:

    componentDidMount() {
        console.log(process.env.REACT_APP_MARKETSTACK_API_KEY)
    }

If all things went correctly, you should see your API key now showing in the console.

Now the API key is hidden we can fetch certain data. Within your React application, we can run fetch.

In one of my components, I'm going to run a fetch request.

We'll break it down into a few parts.

let API_KEY = process.env.REACT_APP_MARKETSTACK_API_KEY

let stockTicker = 'MSFT'

let URL = `http://api.marketstack.com/v1/eod access_key=${API_KEY}&symbols=${stockTicker}`

Let me explain what we did. We set the variable API_KEY to our API Key stored in our .env file. We call it with process.env

We set stockTicker to MSFT for now so that we can include it within our URL, taking our API and providing the previous variables within the link.

This way, we're avoiding hardcoding data, except for the stockTicker which we'll implement later, and reducing the lines of code.

Now, let's run our fetch request.

Most fetch requests are done in this format:

fetch('http://example.com/stocks.json')
  .then(response => response.json())
  .then(data => console.log(data));

Here, we're fetching JSON data from an API and sending it to the console. The data is not instantly set, but instead, we're returned a promise containing the response. We extract that JSON content but using .json() on the response and then can handle that data in different ways such as setting it to state or running console.log.

Data can be anything but make sure that the variable names are consistent. For example, data can be stockData if that helps writing cleaner code. Especially, if you're working with multiple fetch requests.

If you have your own backend

    componentDidMount() {
        this.fetchStock()
    }
fetchStock() {
        let API_KEY = process.env.REACT_APP_MARKETSTACK_API_KEY
        let stockTicker = 'MSFT'
        let URL = `http://api.marketstack.com/v1/eod access_key=${API_KEY}&symbols=${stockTicker}`

        fetch(URL).then(res => res.json())
        .then(data => console.log(data))

What you should get in return is a series of Stock data by day.

There you have it! The next things you could do is map the X axis by day and the Y axis by highs and lows for that day.

How to use Geocoder

Nathan Chung — Tue, 08 Sep 2020 20:45:33 +0000

You're working on your Rails project and you've saved all the addresses. Great!
What do you do now? If you're using the Google API and need to generate markers, you'll need latitude and longitude coordinates.

Geocoder is an amazing gem that takes an address and finds its latitude/longitude coordinates! It can also do it the opposite way as well. Saving the info in the backend can also reduce the API requests you've done in total.

How do you install it?

First, my original model looked like this:

class Activity < ApplicationRecord
  has_many :user_activities
  has_many :users, through: :user_activities
  has_many :comments
end

Now, we want to do two things:

gem install geocoder

then run
bundle install

We've now installed the gemfile and can start using the geocoder.

rails g migration AddLatitudeAndLongitudeToModel latitude:float longitude:float

It will create a migration file within your db/migrate folder

Run db:migrate and make sure it migrates successfully!

Now we're going to make a few additions to our Activity Model.

class Activity < ApplicationRecord
  geocoded_by :complete_address
  def complete_address
    [address, city, state, zipcode].compact.join(', ')
  end

  has_many :user_activities
  has_many :users, through: :user_activities
  has_many :comments
end

We've added geocoded_by :complete_address and also have defined what the complete_address is.

def complete_address
    [address, city, state, zipcode].compact.join(', ')
end

To verify if this is working, we can call
Activity.first.complete_address and if everything worked successfully, you'll be returned your new, complete address. This takes the data from the model and creates a full address.

From here we can call something like this:
Activity.last.geocode
and it will query geocode along with an API and return the coordinates.

Now, to limit requests we make every time our activities are queried we can do an after_validation like this:

class Activity < ApplicationRecord
  geocoded_by :complete_address
  after_validation :geocode, if: ->(obj) { obj.address.present? and obj.address_changed? }
  def complete_address
    [address, city, state, zipcode].compact.join(', ')
  end

  has_many :user_activities
  has_many :users, through: :user_activities
  has_many :comments
end

There you go. I hope you find what you're looking for. ;)

Understanding Task Lister Lite

Nathan Chung — Wed, 26 Aug 2020 04:51:17 +0000

I said I'd cover MVC in my next few posts. Today, I am a liar.

I started mod-3 of Flatiron this week and Task Lister gave me some trouble. It's our first week of javascript and I'm hoping this blog will help break things down.

Let's start off with the HTML.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Flatiron Task Lister</title>
    <link rel="stylesheet" href="./style.css" />
  </head>
  <body>
    <div id="main-content">
      <h1>Task Lister Lite™️</h1>

      <form id="create-task-form" action="#" method="post">
        <label for="new-task-description">Task description:</label>
        <input
          type="text"
          id="new-task-description"
          name="new-task-description"
          placeholder="description"
        />
        <input type="submit" value="Create New Task" />
      </form>

      <div id="list">
        <h2>My Todos</h2>
        <ul id="tasks"></ul>
      </div>

      <script src="./src/index.js" defer></script>
    </div>
  </body>
</html>

The main point of this lab is to allow you to to create tasks and them to the list.

To start off, we'll need to load the HTML before the javascript text.

You can do this in a few ways:

defer

in your index.html you can add defer to the script section so it will look like this:

#index.html
<script src="./src/index.js" defer></script>

DOMContentLoaded

in your /src/index.js file, it should look something like this:

#index.js
document.addEventListener("DOMContentLoaded", () => {
  // your code here
});

or moving the script to the very bottom of the body. That will look something like this:

#index.html
//a bunch of previous code
    </div>
    <script src="./src/index.js" ></script>
  </body>
</html>

Long story short, you'll learn to choose one or the other and run with it. You need to load the HTML before you can run the script and these methods allow the HTML file to fully load before the JS begins.

You can open the index.html file in your browser with an extension called Live Server.
Now, once that's done, here's what it should look like. (Colors may vary).

If you click around, you'll notice nothing works! This is where the javascript comes in.

Let's get it

To start off, we need to create a constant that's identifying the form.

#index.html
      <form id="create-task-form" action="#" method="post">

We can gain access to this by doing a document.querySelector("#create-task-form");

#index.js
const taskForm = document.querySelector("#create-task-form");

Why are we doing this?

The main deliverable is that a user should be able to add a task-based off of their description and then press submit. Then, it should populate below.

Now we have the taskForm variable. We'll need another a few more. We want to take the data from the taskForm and add them this section in the html.

#index.html
      <div id="list">
        <h2>My Todos</h2>
        <ul id="tasks"></ul>

We can do this by using another document.querySelector. It'll look like this:
const taskList = document.querySelector("#tasks");

Wonderful!

Typically with form data, when you press submit a post request will be made. Its default behavior is something we're going to prevent. How?

Through this:

#index.js
taskForm.addEventListener("submit", function (event) {
  event.preventDefault();

This stops what would usually happen when you press submit!

So, great. We've stopped the regular behavior but now what do we want to do with the form data we received? We can take a look at what's being passed through the form.

#index.html
<form id="create-task-form" action="#" method="post">
        <label for="new-task-description">Task description:</label>
        <input
          type="text"
          id="new-task-description"
          name="new-task-description"
          placeholder="description"
        />

This is the section that responds to where we're filling in the data on the website. This input field actually has a value once we press submit. We can access that by doing the following.

#index.js
  const newTask = document.querySelector("#new-task-description").value;

This sets newTask to be the value of the new-task-description field.

So now that we have the value of whatever task we typed in, we need to add that to our taskList.

#index.js
TaskForm.addEventListener("submit", function (event) {
  event.preventDefault();
  const newTask = document.querySelector("#new-task-description").value;

## NEW CODE ##
  taskList.innerHTML += `<li> ${newTask}
  </li>`;

});

We take the *value from #new-task-description and add that to taskList.innerHTML.

Type a new task into your browser and it will look something like this:

You were able to create a new task! Note, once you press submit, the created task is still in the form field. We can delete that by adding the following.

#index.js

const taskForm = document.querySelector("#create-task-form");

const taskList = document.querySelector("#tasks");

taskForm.addEventListener("submit", function (e) {
  e.preventDefault();
  const newTask = document.querySelector("#new-task-description").value;

  taskList.innerHTML += `<li> ${newTask}
  </li>`;
###NEW CODE###
  // taskForm.reset();
});

This takes the taskForm and resets it each time a task is submitted.

Finally, we're going to create delete button. How would we do this? Simple!

#index.js

taskForm.addEventListener("submit", function (e) {
  e.preventDefault();
  const newTask = document.querySelector("#new-task-description").value;

  taskList.innerHTML += `<li> ${newTask}
###NEW CODE###
  <button data-action = "delete"> X </button>
  </li>`;
##############
  taskForm.reset();
});

With each addition of a task, we add a button with the label "X". This could be anything you'd like. We now have a button but if you press it, nothing will happen. We need to create one more function that will "listen" for a click.

#index.js
taskList.addEventListener("click", function (e) {
  if (e.target.dataset.action === "delete") {
    e.target.parentElement.remove();
  }
});

We create another Event Listener that's waiting for a user to click on the x. Once we do that, we're making sure that if the action, delete, of the function matches with <button data-action> we remove the parent element of the button which will be the full list item.

Without the parentElement specified, you will only be able to delete the button and not the full task.

Try it out!

Grabbing Coffee with MVC

Nathan Chung — Wed, 12 Aug 2020 20:26:53 +0000

This is the first post of a RAILS series directed at Flatiron students.

Congratulations!

You've just finished mod 1. Well done.

You've crushed enumerables into your brain, built your first CLI app, and now you're being introduced to a totally new topic called Rails. Woah.

First, let me say this. It's going to be stressful and it might feel overwhelming but we'll get through this. For now, let's take a deep breath.

I'll give you a moment.

inhale

exhale

Ruby on Rails is a wonderful and "magical" framework that allows developers, like you, to rapidly build massive applications. For example, Github & Airbnb both use Rails in their stack.
Here’s a link to 34 companies using rails. Just like how active records simplifies some methods for us, Rails does as well. Today, I'll be teaching you one aspect of it: MVC.

Model, View, and Controller Architecture

Model, View, and Controller, MVC, is a way to have a separation of concerns amongst components.

What does this mean?

"Separation of Concerns is achieved by encapsulating information inside a section of code that has a well-defined interface. It is easiest to think of in terms of modularity."

This is a great way to say the model, view, and controller deal with their own problems and methods. Model problems deal with model problems, view problems deal with view problems, and controller problems deal with? You guessed it. Controller problems.

You're dividing the work of an application into three separate systems. Why is this good? It allows developers to easily identify problems, test methods, and scales as your application grows.

Model

The model component deals with data-related logic. It handles the relationship between the data and databases, validations, and associations between models.

Think about when we kept our data in our methods class. Now we keep data in our db and our class methods in a model.

Note, how would you get that all the way a user? Most would and should not need to know about all that information in the backend.

In our example, we'll call the model a barista.

View

The View presents the model’s data to the user. The user can see the data and the pretty layouts but when they want to modify layout or content, they're actually using a controller that communicates to the model.

The view is the counter where you see the menu and order your goods.

Controller

The controller is a link between your views and your model. In Rails, the controller handle requests from the users and communicates to the model-based off on the type of request made.

This will be the cashier!

Putting it all together.

Let's take an example of you entering a coffee shop.
You, self.name, enter a coffee shop and walk up to the counter(view) to order your coffee. You browse the menu at the counter (view) through a list of things you can order. You can view desserts, sandwiches, and coffee.

The cashier greets you with a warm welcome.

"Hello, I'm Nate, your controller what can I do for you?

drip? Nah.
Ooo, do I want a pour-over? Had that yesterday
Hm... I know.

"One americano, please.

Nate, the cashier/controller, receives your request and yells "AMERICANO" to the barista(model) in the back. He just told the model what to do and then smiles back at you asking "anything else?"

no, I'm good.

You, AND the cashier, don't need to know that that a good espresso needs 9 bars of pressure, 30 pounds of pressure on a 51mm diameter tamper, and should hit a ratio of 36ml to 25seconds for a proper extraction.

The barista(model) alone holds all that coffee-related knowledge.

The cashier(controller) is simply routing your request that you made at the counter(view) to the barista(model).

You, as the end-user, just want good tasting coffee to push you through another lab.

How does the barista(model) know what to make? By the cashier (controller)!

Now, the barista(model) has just finished your coffee. Are you going to go behind the counter and grab the coffee?

You can...but you'll probably also be banned from the shop.

Nate, the controller, will grab that americano and hand it back to you at the counter.

Voila! You've just experienced an MVC framework.

You made a request for an americano to the cashier(controller). The cashier just routed the specific request to the barista(model) who used their deep knowledge of coffee-brewing to make you a specific kind of coffee. They could have made you any type of coffee.

Affogatos, cappuccinos, macchiatos, and just about anything else! However, because they were given specific instructions by the cashier, the barista(model) made the americano that you requested.
After creating the americano, they hand it to the cashier/controller and they hand it to you back at the counter.

Here’s a quick diagram to wrap up what happens!

There could have been plenty of errors here.

The barista may not have known how to make an americano. That'd be a problem with the model.
The cashier may have had no idea how to process your credit card. That'd be a problem with the controller.
You may have asked for something that's not on the menu. That'd be a problem with you. (no offense)

With the MVC framework, problems and solutions are easy to identify.

I'll continue discussing MVC and increase the specificity over the next few blog posts! Comment below any questions and concerns you may have.

Icons made by ultimatearm from www.flaticon.com

Awesome title

Nathan Chung — Wed, 12 Aug 2020 00:15:18 +0000

This is my awesome content.