Forem: Daniel Troyano

Setting up a Basic React.js Front End for your Rails Server

Daniel Troyano — Sat, 26 Sep 2020 15:27:19 +0000

So if you've been following along you have a basic Rails server that is returning JSON.

Now let's hook it up to a basic React.js front end.

We're going to use the react-rails gem to hook up React with Rails. So let's add it to our Gemfile. Just add the line gem 'react-rails' in there, and then we need to run several commands in the terminal.

bundle install
rails webpacker:install
rails webpacker:install:react
rails generate react:install

And we have React.js hooked up in our Rails sever. Now we need to write our React.js components to talk to the back end.

But before we do that we have a couple more things to take care of in our Rails server. We're going to be serving up a static page with our React.js code so we need to tell Rails how to show that.

So, let's generate a home controller with rails g controller Home. Don't worry this controller is going to be incredibly simple. So first, let's add a route for it. Go ahead and add root 'home#index' to your config/routes.rb. This will route your root directory to our home controller, which is just going to show our React.js page.

So let's set up our app/controllers/home_controller.rb now.

class HomeController < ApplicationController
  def index
  end
end

That's it. In this case, all we want to do is say that it exists. That way Rails will render the view. Let's set that up now as well. Create a app/views/home/index.html.erb.

<%= react_component 'app' %>

That's it. That's the whole file.

Let's grab axios real fast so our front end can talk to our back end. So go ahead and run yarn add axios.

And now we can actually start writing React.js and we just want to name our component the same as the one we called in our index.html.erb, because that's what's going to show up. So create a app/javascript/components/app.jsx file. This is where Rails is going to look for our components.

So let's setup up a very basic React.js component.

import React, { useState, useEffect } from 'react';
import axios from 'axios';

const app = () => {
  const [dogState, setDogState] = useState([]);

  useEffect(() => {
    axios({
      method: 'GET',
      url: '/dogs'
    })
    .then(({data}) => {
      setDogState(data);
    })
  }, []);

  return (
    <div>
      <h1>These are our dogs</h1>
      {dogState.map((dog, i)=>(
        <div key={dog.id}>
          <p>{dog.name} age: {dog.age}</p>
        </div>
      ))}
    </div>
  )
}
export default app;

Here we set up the starting dog state with an axios call in our useEffect. And then we just display a list of those dogs. But we want to do more than that. Let's add a form to add a new dog to the list as well!

Go ahead and add this inside the outermost div tag in our return statement.

<form>
  <label>Name:
    <input onChange={changeHandler} type="text" id="name" value={dogInfo.name}/>
  </label>
  <label>Age:
    <input onChange={changeHandler} type="number" id="age" value={dogInfo.age}/>
  </label>
  <button onClick={addDog}>Add Dog</button>
</form>

This is a very basic form, but it's looking for some stuff we don't have yet. Notable a changeHandler function, an addDog function, and a new state to manage the form.

First let's add our new state that will manage the form and give it some initial values.

const [dogInfo, setDogInfo] = useState({name: '', age: 0});

Now let's set up our changeHandler function that will update the dogInfo state whenever you change one of the form inputs.

const changeHandler = ({target}) => {
  setDogInfo((prev) => ({...prev, [target.id]:target.value}));
}

And now we will also add the addDog function that calls our API route.

const addDog = (e) => {
  e.preventDefault();
  axios({
    method: 'POST',
    url: '/dogs',
    data: dogInfo
  })
  .then(({data}) => {
    setDogState((prev) => {
      const newList = [...prev];
      newList.push(data);
      return newList;
    });
  })
};

We call our Rails API exactly how we would call any other backend. It's easy peasy. Then we update our dog state with the new information. Notice how we're returning a new object so React knows to update the dom.

So now that we can add a dog, we need a way to remove and edit a dog. So let's add those buttons to our map. So just update it to look like this.

{dogState.map((dog, i)=>(
  <div key={dog.id}>
    <p>{dog.name} age: {dog.age}</p>
    <button onClick={()=>removeDog(dog.id, i)}>Remove</button>
    <button onClick={()=>updateDog(dog.id, i)}>Update</button>
  </div>
))}

We'll need to add those functions to our component as well. So let's add them.

const removeDog = (id, i) => {
  axios({
    method: 'DELETE',
    url: `/dogs/${id}`
  })
  .then(() => {
    setDogState((prev) => {
      const newList = [...prev]
      newList.splice(i, 1);
      return newList;
    });
  })
}

const updateDog = (id, i) => {
  axios({
    method: 'PUT',
    url: `/dogs/${id}`,
    data: dogInfo
  })
  .then(({data}) => {
    setDogState((prev) => {
      const newList = [...prev];
      newList[i] = data;
      return newList;
    })
  })
}

These two look very similar to the addDog function, because they are. We just make the relevant axios call and then update the state on the front end with the response that we get back.

I've omitted all my error checks and this is a very bare bones component. But the important thing to observe here is that this is just a regular React.js component.

And that's it. This was a very basic walk through of how to get a CRUD Rails server up and running with a React.js front end that talks to it. Just remember that we're working with simplified examples here, but hopefully this gave you the courage to try it out on your own!

Setting up a Basic CRUD Rails API

Daniel Troyano — Sat, 26 Sep 2020 15:24:56 +0000

So you've run rails new and you've got a brand new blank Rails application waiting for you. Let's turn it into a CRUD API that interacts with a list of dogs.

First things first, let's get our dogs table set up in the database. Rails uses Active Record, an ORM, to abstract your calls to the database. To interact with our schemas we're going to need to create a migration.

Migrations are great because you can just write Ruby code to interact with the database and don't have to worry about specific database commands. But they are also great for version control and making sure that your database is set up the same way in every environment.

So let's run rails generate model Dog, which can be shortened to rails g model Dog. Models should be named in Pascal case and also be singular. This is going to generate a dog model and a create_dogs migration, which will have a date time code attached to it as well. It's very important for Rails to know the order to run the migrations in, so it always prepends a timestamp.

Open up your brand new migration and let's give our dogs some characteristics.

class CreateDogs < ActiveRecord::Migration[6.0]
  def change
    create_table :dogs do |t|
      t.string :name, not_null: false
      t.integer :age, not_null: false
      t.boolean :good, default: true
      t.timestamps
    end
  end
end

When we run this migration it will run its change method. Which will create the dogs table and then fill it with the columns you tell it. In this case we want a name, which is a string and can't be null, an age, which is an integer and also can't be null, and a column to track if the dog is good, which is a boolean that of course defaults to true.

I have also left in the timestamps so that Rails will automatically create created_at and updated_at columns and keep them updated.

Now run rails db:migrate and you should see a create_table command is run. Hooray! You have created a table to track your dogs.

Let's pop over and open up our app/models/dog.rb that our generator created for us. Notice that it's empty. That's fine. This is where we would put in any validations, associations with other pieces of data, or any computed logic that has to do with this model.

We don't need to make any changes to it though, but it's good to know about.

Now let's make a controller.

Run rails g controller Dogs, controllers should also be in Pascal case but they should be plural. So now you have a app/views/dogs folder and you have a app/controllers/dogs_controller.rb. Before we set up your controller, let's set up our routes to handle our intended actions.

Open up your config/routes.rb, it should have basically nothing in it. And we want to be able to create a dog, see all the dogs, see a specific dog, update a dog, and delete a dog. So let's add a line that lets us do that.

Rails.application.routes.draw do
  resources :dogs, only: [:create, :index, :update, :destroy]
end

Resources tells Rails that we want to be able to interact with the given resource, so it should make some standard RESTful routes for us. If you leave it at that Rails will set up a couple extra routes that would handle forms for adding a new dog or updating a dog and a route for showing a single dog, but since our front end is going to handle that, we specify we only want the routes listed here.

Now if you run rails routes you'll see all the routes that Rails creates for you. There's probably a bunch about mailboxes, don't worry about them, these are ones we're going to focus on.

Prefix Verb    URI Pattern              Controller#Action
dogs  GET      /dogs(.:format)          dogs#index
      POST     /dogs(.:format)          dogs#create
dog   PATCH    /dogs/:id(.:format)      dogs#update
      PUT      /dogs/:id(.:format)      dogs#update
      DELETE   /dogs/:id(.:format)      dogs#destroy

You should be able to recognize those prefix verbs as HTTP Verbs. They map to a URI, which is the actual route that you are going to be hitting, notice how plenty of them also get an id. And then we have controller actions, these are the methods that Rails will use to dictate the logic when you hit one of those routes.

So let's open up our app/controllers/dogs_controller.rb and start adding methods.

Let's start with our index method, which will show all our dogs.

class DogsController < ApplicationController
  def index
    render json: Dog.all
  end
end

The index method is going to find all the dogs, and we want to specify that it returns json. The Dog we're referring to here is the model which inherits from ApplicationRecord, so we can use Active Record to interact with our database.

Currently, there's no dogs in our database, so let's create a method that allows us to add some!

def create
  dog = Dog.create(dog_params)
  render json: dog
end

private 

def dog_params
  params.require(:dog).permit(:name, :age)
end

In the create method we create a new Dog with the params we were given. Notice we do that by calling a second, private, method though. Rails protects you against malicious users by making sure you use Strong Parameters. This prevents users from passing unintended things into your database. But it also means you have to tell Rails what you're expecting to get. Which we do in the method dog_params.

Now, let's add our update method.

def update
  dog = Dog.find(params[:id])
  dog.update_attributes(dog_params)
  render json: dog
end

Here we find the current dog by id and the update its attributes with the passed in parameters. Even if you aren't super familiar with Ruby, part of what I love about it is how readable that code is.

And finally to fill out our CRUD application let's add a destroy method.

def destroy
  Dog.destroy(params[:id])
end

Once again, I imagine this is very clear. We destroy a dog based on the given id.

Now before you run rails s and check out your API we need to add one line to our app/controllers/application_controller.rb that our dogs controller inherits from. See, Rails is once again protecting us by expecting us to provide an authenticity token along with any request that alters the data. But since we're just building this for fun, we don't need to worry about that.

So open up the application controller and add one line, so that it looks like this.

class ApplicationController < ActionController::Base
  protect_from_forgery
end

protect_from_forgery is the same as writing protect_from_forgery with: :null_session, which just allows the request through, but removes the session. This isn't secure at all so don't do this in the real world unless you have a really good reason, but it's fine for this.

Now you can run rails s and hit the routes you set up. Although you'll probably need something like Postman to get to most of them. But don't worry, we'll be hitting them in a sec with our React.js front end.

Setting up a Basic Rails Server

Daniel Troyano — Sat, 26 Sep 2020 15:23:45 +0000

In this series I'm going to walk through setting up a very basic Rails server. Then we're going to turn it into a basic CRUD API that returns JSON. And then finally we're going to setup a React.js frontend for our API.

Alright, let's hop into setting up our basic Rails server!

So, I'm going to assume you have Ruby installed already. If you don't I would recommend installing Ruby Version Manager. Also make sure you have Rails and SQLite installed, since we'll be using that later. If you don't, check out Install Rails.

Ok, let's begin for real now.

Rails has a lot of handy command line tools that we're going to be using, we'll go over them as they come up, and here we're going to use rails new dog_api to create a new Rails application. dog_api can stand in for whatever you want your application to be called, but we're going to make a list of good dogs, so that's what we're calling it.

Your computer will probably take a little while to generate the application, but when it's done, hop into your new folder and check out all the work that's already been done for you.

There's a lot going on here, and it can look really intimidating, so let's talk about what we want to focus on.

First let's look at the app folder. This is where you're going to be doing most of the work for these basic projects.

Rails is a MVC Framework. So most of what we'll be doing are in the models, views, and controllers folders. One of the great things about Rails is that it's really smart as long as you use proper naming conventions. For instance if you have a file in models called dog.rb it will know to look for a dogs_controller.rb in the controllers folder. And the methods in your controller know to look in views/dogs for matching files. So the index method will look for a index.html.erb to render.

I'll go into this a little more when we make our CRUD API.

There are two more folders we're going to look at very minimally for this tutorial. Let's glance at the db folder first. In here we can check out our migrations, which is how Rails manages changes to our database. Or use seeds.rb to create some initial entries in our database.

We'll also need to just pop into our config folder and look at our routes.rb. There's a lot of great stuff going on in here that pertains to setting up your environment and Rails has some great ways to separate your different environments.

But that goes beyond my scope here. The routes file is all we're really going to interact with here, and it handles all of the routing in your app, so we'll be using that for our CRUD API in a bit.

Now that you have a basic understanding of the file structure of a Rails application, let's start up that server.

Run rails server which can be abbreviated as rails s. Now navigate to localhost:3000 in your browser.

That's it.

Granted this is just Rails' basic example page. But I'll go into how to customize it in the next part of this series.

Coming from JavaScript to Ruby

Daniel Troyano — Sun, 20 Sep 2020 01:21:56 +0000

So let's say you're got a handle on how to create a Node.js server and you want to expand your horizons. You've been hearing a lot about Rails, a popular MVC framework, and want to give it a try. But it uses Ruby, a completely different language!

Let's take a quick look at Ruby to see if learning another language is as scary as it sounds, (pro tip, it's not).

I'm not going to go into how to install Ruby on your computer, if don't already have it, I would recommend installing Ruby Version Manager for the same reasons you've probably been using Node Version Manager.

Ok, so you have Ruby installed and you want to give it a whirl! Well just open up your terminal and run irb. This starts up Interactive Ruby! It's a way to test out and run Ruby code right in your terminal.

We're going to be writing everything in irb, but if you wanted to, you could also make a file called something like test.rb and put all the code in there and use ruby test.rb in your terminal to run it. I'll use comments to denote the results of the code. Notice Ruby uses # instead of //.

Ok, so first of all, you don't need to use semi colons anymore! Ruby doesn't need anything to end a line. While yes, technically, you can use them to chain multiple commands on one line you definitely don't need to use them to end a single line. Also in Ruby, variable declaration is super easy. There's no more var, let, or const. Instead. you just write name = "Daniel". And now the name variable is set to a string of Daniel.

So if we wanted to declare several variables and print them to the screen, kind of like a console log, we could do this.

name = "Daniel"
age = 34
puts "Hi my name is #{name} and my age is #{age}"
# Hi my name is Daniel and my age is 34

Notice I snuck in string interpolation there too! It looks pretty much just like JavaScript, except with a # instead of a $. But it's important to know that in Ruby it only works with double quotes, not single quotes or back ticks, like in JavaScript.

Ruby is a pure object oriented language, so every variable is a reference to an object. This means that there's no difference in the way that it handles what JavaScript would call Simple or Primitive DataTypes.

Let's take a look at an example of that.

my_dog = "washburne"
my_favorite_dog = my_dog
my_dog.upcase!
puts my_favorite_dog
# WASHBURNE

As you can see changing my_dog changed my_favorite_dog. Let's talk a little about how we did that, because this is a very cool convention in Ruby. If a built in method in Ruby returns a changed copy of a variable, then you can affix a ! to the end of it to have it change the original. Also if you see a method end in ? that means it is going to return a boolean.

These are good conventions for your own methods as well!

Another big change is that JavaScript has objects, but the equivalent in Ruby is a hash. Like objects, hashes are key value pairs but the keys can be anything. So this is a valid hash in Ruby.

my_car = {
  "color" => "blue",
  "wheels" => true,
  4 => nil
}

Yes, I know none of those values made sense. But I just wanted to show they are possible. Now, normally when you use hashes you're going to use symbols for the keys. This is because symbols are faster and immutable. Even though "Danny" == "Danny" is true, if you were to check "Danny".object_id == "Danny".object_id it would be false. This is because they are pointing to different objects.

But that isn't true for symbols. They look like :name and two symbols with the same characters are exactly the same. So :name.object_id == :name.object_id would be true. So you could declare a hash like this.

my_car = {
  :color => "blue",
  :wheels => 4
}

However, there is an even shorter syntax that you can use when using symbols.

my_car = {
  color: "blue",
  wheels: 4
}

I imagine that looks really familiar to anyone coming from JavaScript. But you do need to keep in mind that it is working a little different in Ruby. Something to note is that you can't use dot notation to access the information in that variable. To get the color you would need to write my_car[:color].

Hopefully this small glance at Ruby has given you the courage to check it out. There are tons of helpful guides out there to help you along your way. I would recommend The Odin Project.

ps. I didn't even mention that Ruby uses == to check equality, but I bet you picked up on that.

Setting up a Basic Next.js Application

Daniel Troyano — Sun, 13 Sep 2020 18:24:05 +0000

Next.js is an end to end framework that is built on top of React.js and Node.js. Which means it is a single framework that stretches over your front and back end. This means most of your front end code looks like React.js and most of your back end code looks like Node.js.

Even though the code looks very familiar, Next.js brings a lot to the table and there are plenty of reasons it is one of the most popular back end javascript frameworks. Here are just a few:

Zero Configuration. Out of the box Next.js is set up to compile and bundle your code.
Static Page Generation. It is remarkably easy to set up and easily increase your application's SEO and speed.
File System Routing. Routing is incredibly simple and helps keep relevant code together.

There are plenty more reasons to use Next.js and you can check them out at their documentation. But I'm going to focus on those three for this article.

Next.js has a command line tool to bootstrap an app for you, but I'm not going to use that here, because I think making it yourself really helps you understand what's going on.

So first, we need to install some packages. npm i next react react-dom That's all we're going to need today. However, we're also going to need to set up our package.json to have our scripts run next commands so add these.

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start"
}

next dev starts up a development server with Next.js
next build compiles the code for production
next start starts the Next.js production server

One of Next.js' cool features is Hot Reloading with React Refresh. So you only have to run npm run dev once for this demo and your code will automatically update, it will even attempt to preserve your React State if it can.

Now let's talk about how Next.js handles routing. In your root directory make a pages directory. Now make a file called index.js in there and we're going to make a very basic React component.

const Home = () => (
  <div>
    My Next.js HomePage
  </div>
);

export default Home;

That's all you need. You don't even need to import React. Now if you run npm run dev and navigate to http://localhost:3000 you can see your application.

The pages directory controls routing through file names. So if you put an about.js in your pages directory the url would be http://localhost:3000/about. But it also works with folders so if you made a profile directory in pages and created an index.js in there, its url would be http://localhost:3000/profile.

Next.js also provides a React component to handle client-side navigation. So we could modify our index.js to get around to all our other pages like this.

import Link from 'next/link';

const Home = () => (
  <div>
    My Next.js HomePage
    <Link href='/about'><a>About</a></Link>
    <Link href='/profile'><a>Profile</a></Link>
  </div>
);

export default Home;

This all looks like basic React code so let's spice it up a little with some server code.

Let's make our about page and take advantage of Next.js' Static Page Generation. Static Generation occurs when we build our Next.js application, and it generates the HTML for our page. This means it can be cached by a CDN and crawled by a Search Engine. Which means it's easier for your users to find, and your site loads faster for them as well.

If your page doesn't incorporate any data Next.js is already going to use Static Generation to build it, but it can also do that if you are using data. This is especially useful for things that you don't expect to change often, like blogs or in our example contact information that's stored in a database.

So let's open up our about.js and give it some content.

Don't worry too much about the import at the top here, it's just a database helper to get our users' data.

import userHelpers from '../../database';

const About = ({ users }) => (
  <div>
    About
    <ul>
      { users.map(user => (
        <li key="user.id">
          {user.email}
        </li>
      )) }
    </ul>
  </div>
);

export const getStaticProps = async () => {
  const response = await userHelpers.getAllUsers();
  const users = JSON.parse(JSON.stringify(response));
  return {
    props: {
      users,
    },
  };
};

export default About;

Notice that we have our React code up at the top taking in props, this all looks very familiar. But down below we have getStaticProps this is server side code that we can write here since it pertains to this page and when Next.js builds our application it won't bundle it with the client side code so you can even use database helpers. Next.js is even smart enough to know that we used that import statement in our getStaticProps so don't bundle it with the React code.

So, at build time Next.js takes the props that we return from getStaticProps and passes them into our React function and uses that to generate some HTML for our client.

Hopefully this got you interested enough in Next.js to go give it a try. It has a ton of other really interesting features. Such as dynamic routing through file names, and a way to dynamically pre-render pages for dynamic routes. It can also easily handle Server Side Rendering. And it supports CSS modules right out of the box.

This is only the tip of the iceberg, Next.js has a lot to offer and if you're used to writing React and Node.js code than it's very intuitive and easy to learn.

How to Manage a Store with Vuex

Daniel Troyano — Sun, 06 Sep 2020 15:59:10 +0000

So your Vue application is growing larger and larger and it's getting harder and harder to manage all the disparate local states in your components. Wouldn't it be great if you had just a single point of truth for all of your data?

Well thankfully, Vue has Vuex, a state management pattern and library for Vue. Vuex makes it easy to maintain a one way data flow with your global state so that you can easily track and control any changes and maintain consistency throughout your application.

State is rendered to the components. If you want to change something, you call an action which makes a mutation, which changes the state. It may seem like actions and mutations should be the same step, but the difference is that mutations must be synchronous and actions can be asynchronous. So you can make API calls or talk to a database in an action. And when the action finishes you can tell a mutation to change the state with the new information.

Now that you have a basic understanding of a Vuex store, let's take a look at how we would implement it.

In our top level component, we need to import Vuex and set up a new store.

import Vue from 'vue'
import Vuex from 'vuex';
import App from './App.vue'

Vue.use(Vuex);

const store = new Vuex.Store({
  state: {
    users: [],
  },
});

new Vue({
  render: h => h(App),
  store,
}).$mount('#app')

We're going to be rendering a list of users that we're getting from a fake api called ReqRes. So we set up the initial user state as an empty array.

We're also going to need a way to mutate that list. So let's set up a mutation to load our users.

const store = new Vuex.Store({
  state: {
    users: []
  },
  mutations: {
    loadUsers (state, payload){
      state.users = payload.users;
    },
  },
});

Notice that our mutation takes the current state and a payload as its parameters. We need the state, so that we can mutate it, and the payload is how we're going to change it. Technically we don't need a payload, but if you are passing any information into the state you will end up using it.

Also notice we haven't made that api call yet, because a mutation has to be synchronous and we don't know how long it will take to make that external call.

So now let's add our action so we can get those users.

const store = new Vuex.Store({
  state: {
    users: []
  },
  mutations: {
    loadUsers (state, payload){
      state.users = payload.users;
    },
  },
  actions: {
    getUsers ({ commit }) {
      axios({
        method: 'get',
        url: 'https://reqres.in/api/users',
      })
        .then(({ data }) => {
          const users = data.data;
          commit({
            type: 'loadUsers',
            users,
          });
        });
    },
  },
});

Actions take two parameters as well, but here we're only using the first, which is context, and destructuring commit out of it. Context can be used to access the state or other actions if you want but we're only going to use commit which is how you call a mutation. The second, optional, parameter is for if you want to pass any data to your action.

There are a few different ways to call commit. All of these are valid, but they all work a little differently.

commit('loadUsers', users);
commit('loadUsers', { users });
commit({
  type: 'loadUsers',
  users,
});

I prefer the final one, but if you want to read about them all check out Vuex's Documenation.

However you call commit, it finds the corresponding mutation and changes the state based on what you pass it. And then, because Vue is reactive, the state will trigger changes throughout the application where ever you are using it. So let's take a look at a component and how you can interact with the Vuex Store.

export default {
  name: 'App',
  computed: {
    users() {
      return this.$store.state.users;
    },
  },
  methods: {
    loadUsers: function () {
      this.$store.dispatch({
        type: 'getUsers',
      });
    },
  },
};

Now that we have a Vuex Store, in any component we can access it with this.$store.state as you see me doing in computed here. This links the local users up with the store's. However, we can't just change it, we have to use actions.

So let's set up a method, loadUsers, to handle calling our action. When we want to call an action we use dispatch and to get a hold of our store's actions we just call this.$store.dispatch and pass in the name of the action we want to call as the type.

Just like commit, there are several ways to call dispatch but I prefer the object style. If you want to check out the others look to Vuex's Documenation on actions.

So now whenever we call the loadUsers method in our App component, it calls an action that talks to an api and gets back some users. Once it has the users it calls a mutation, which changes the users state in our store. Then our App component sees that users has changed and updates our page with the new list of users. One way data flow in action!

There's a lot more to Vuex as well, such as separating your store into different modules when it gets too large, or setting up 2 way binding with getters and setters. But hopefully I have piqued your interest enough for you to go check out Vuex and figure out how to use it for your application.

Testing with Mocha

Daniel Troyano — Sun, 30 Aug 2020 20:26:05 +0000

Normally, after you get done writing your code, you have to test your code by thinking of every way someone might interact with your application, and then manually trying all those things to make sure it doesn't break. Well wouldn't it be great if something could run all those tests for you? That's what Mocha does.

Mocha is a testing framework for Node.js. Which means it can execute all those tests for you and let you know if your code holds up.

Let's assume you have a Node.js server already set up and you have it hooked up to a database.

Great! Now let's test it to make sure it's working.

First things first let's install the dependencies we'll need for this.

npm i -D mocha chai chai-http nock

Mocha is our testing framework. Chai is an assertion library. There are several different ones, but we'll be using Chai. Chai HTTP is used to make requests to our server. And Nock is used to load up a fake response so we can reliably test our api.

Before we do anything let's add a script to our package.json file.

  "test": "mocha --exit"

This will run all the tests we have in our /test folder. We include exit because test responses hang sometimes, and we want the tests to stop running after all the tests pass. If you want to debug exactly why this is happening you can use wtfnode. But exit doesn't really hurt anything.

Ok, so let's make a set of tests to test our routes.

First let's take a look at how a test works with Mocha and Chai when you're using Behavior Driven Development, which is what I'll be using.

describe('Name of the User Story', function() {
  beforeEach('Runs before each test', function() {
  });

  afterEach('Runs after each test', function() {
  });

  context('Start of a narrative', function() {
    it('should do something', function() {
      // Actual testing code
      expect(value).to.be(otherValue)
    });
  });
});

In the above example, describe is a way to display a description and group your tests together, and context is just an alias for describe. The two only exist as seperate entites to make your code easier to read.

In addition to beforeEach and afterEach, there are several hooks you can use to interact with your testing environment and get it ready for the test you are about to do. If you want to know more about them check out mocha's documentation.

Finally there is the it block. This is where the actual test is run. Depending on your assertion library and the interface you choose, you can have several different things here. I like expect and it's what I'm going to use here. But chai's documentation talks about the other kinds.

Now that you're familiar with the Mocha pattern, let's look at an actual test.

const chai = require('chai');
const chaiHttp = require('chai-http');
const app = require('../server');

chai.use(chaiHttp);
const { expect } = chai;

describe('Books can be found and added', function() {
  let request;

  beforeEach('Setup Request', function() {
    request = chai.request(app);
  });

  context('GET /books', function() {
    it("should return an array", function(done) {
      request.get("/books").end((err, res) => {
        if (err) done(err);
        expect(res.body.books).to.be.an("array");
        expect(res.body.books[0]).to.have.property("name");
        done();
      });
    });
  });
});

At the top we import the packages we need and our app, so that we can make requests to it. Then we tell Chai to use chaiHttp so that we can make requests. We also grab our interface from Chai.

In our beforeEach we set up our request object. Calling chai.request(app) starts the app listening for a request.

Then in our test we do a GET request to /books and we expect the result to be an array and the first entry in that array to have a name property.

Part of the beauty of using expect is that the tests are very readable by humans.

Notice our use of done here. Done is an optional parameter you can pass into either a hook or a test if you expect it to be asynchronous. That way the test won't move on until it is done().

Let's also go over nock, which we will use to send a fake response back from a given url. We're going to use it to spoof an api call so that we can control our testing environment.

So go ahead and require nock, and some fake data, as json.

const nock = require("nock");
const fakeData = require("./fakeData.json");

Now let's set up our test for our api call.

describe("We want to be able to get data back from the api", function () {
  let request;

  beforeEach("Setup Request", function() {
    request = chai.request(app);
    });
  });

  context("GET /api/books", function() {
    it("should get a response from the api", function(done) {
      nock("http://fakeapi.com")
        .get("/books")
        .reply(200, fakeData);
      request.get("/api/books").end((err, res) => {
        if (err) done(err);
        expect(res).to.have.status(200);
        expect(res.body).to.be.an("array");
        done();
      });
    });
  });
});

This example is pretty similar to the previous one, except we are adding nock in. Nock is going to spoof the first call it sees to the given url and reply with, in our case, fakeData. This is to guarantee that when our app makes its call to http://fakeapi.com/books it gets back exactly what we want. We aren't testing that the api is working, instead we're only testing the way we are talking to it.

Now all you have to do is run npm test to see if your tests are passing!

These may not seem like especially robust tests, but they are only the beginning. Only you know what your code needs to test, so you're going to have custom build any tests you need. Have fun! I hope this has been enough information to start doing just that.

Setting up a Phaser 3 Project using the Matter Physics Plugin

Daniel Troyano — Sun, 23 Aug 2020 00:42:21 +0000

Phaser 3 is an open source JavaScript video game framework made to run in browsers.

It's easy to use, and if you know JavaScript, should be a breeze to start learning.

We're going to be setting it up with the Matter physics plugin, this will give us quick and easy access to collision detection and movement for our game objects.

Let's go through the basic setup that you'll need for basically any Phaser 3 project.

To start off, you're going to need to import Phaser 3, either through their CDN or by importing it as a package. We'll also need to create a html file that has a <div id="app"></div> and imports your index.js. Whenever you want to run your game just use live-server to host your index.html file.

We're also going to need to import the Matter physics engine for Phaser 3. You can get it here. This is going to let us get some cool physics up and running fast.

And now we need to setup our index.js file.

import Phaser from 'phaser';
import PhaserMatterCollisionPlugin from 'phaser-matter-collision-plugin';
import GameScene from './GameScene';

const config = {
  width: 512,
  height: 512,
  backgroundColor: '#000000',
  type: Phaser.AUTO,
  parent: 'game',
  scene: [GameScene],
  scale: {
    zoom: 1
  },
  physics: {
    default: 'matter',
    matter: {
      gravity: { y: 0 },
    }
  },
  plugins: {
    scene: [
      {
        plugin: PhaserMatterCollisionPlugin,
        key: 'matterCollision',
        mapping: 'matterCollision'
      }
    ]
  }
};

new Phaser.Game(config);

Here we are just initially setting up the look of the Phaser game canvas. Most notably, we're setting the size and color. And then we're doing some initial set up on the Matter plugin. We want the y gravity to be 0 because we're going to be making a game in space, so we don't want any gravity.

Now let's set up our scene, which will handle all our game logic. In a more advanced game, you can have multiple scenes, but for ours, we only need one.

import Phaser from 'phaser';

export default class GameScene extends Phaser.Scene {
  constructor() {
    super('GameScene');
  }

  preload() {
    // Called before the scene is created
    //  used to load assets
  }

  create() {
    // Called once when the scene is made
    //  used to do any initial setup of the scene
  }

  update() {
    // Called every game step
    //  used to update the game elements
  }
}

Notice that our scene is using class and is extending Phaser.Scene so we need a constructor method and we want to call super so that we can start using this to refer to this scene. We also set up a few more methods that are going to be useful for a scene.

Ok, now we're ready to start really diving into how Phaser 3 works. Check out my next article to see how you can really reinforce JavaScript fundamentals with Phaser 3.

JavaScript Fundamentals with Phaser 3

Daniel Troyano — Sun, 23 Aug 2020 00:41:52 +0000

Lately I've been working with React a lot so I haven't been writing much actual JavaScript code. But thankfully, I've been learning Phaser 3 on the side and as it turns out, that is a great way to reinforce JavaScript fundamentals.

Most prominently, Phaser 3 requires a solid understanding of this but it also makes heavy use of the ES6 PseudoClassical instantiation pattern.

This walk through is designed to show you how to make a simple spaceship game, but more importantly reinforce some core JavaScript concepts. So for the sake of keeping this concise I'm going to brush past a lot of intro Phaser concepts and focus on the parts that emphasize JavaScript core concepts.

I'm going to assume you've already followed all the steps in the first part of this series. And you already have an empty scene set up.

Most of what we're going to do in our scene is going to involve our game objects, so let's make those first. Since we have several things that we want to be able to move around and hit and potentially die, let's make one object that does all those things that the others can inherit from!

So make a MovementEntity.js.

import Phaser from 'phaser';

export default class MovementEntity extends Phaser.Physics.Matter.Image {
  constructor(data){
    const { scene, x, y, texture, name, health } = data;
    super(scene.matter.world, x, y, texture);
    this.x = x;
    this.y = y;
    this.health = health;
    this._position = new Phaser.Math.Vector2(this.x, this.y);
    this.name = name;
    const { Body, Bodies } = Phaser.Physics.Matter.Matter;
    this.collider = Bodies.circle(x, y, 24, {
      isSensor: false,
      label: `${name}Collider`
    });
    const compoundBody = Body.create({
      parts: [this.collider],
      frictionAir: .3,
    });
    this.setExistingBody(compoundBody);
    this.scene.add.existing(this);
  }
};

We will declare these objects with the keyword New so we've made this a class that extends a Matter Physics Image, because we want it to have physics. Note how we're destructuring what we want out of the data we get from our constructor and passing it back into super. Then we start using this to set up all of the variables we want every MovementEntity to have.

I'm not going to go into how to make a collider, but know that it's what we're using for hit detection. We then attach it to our object and add the MovementEntity to the scene.

However, we're going to need a couple more methods. Let's set up two getters, one so that we can always have access to the object's position, and one to know if it has run out of health.

get position() {
  this._position.set(this.x, this.y);
  return this._position;
}

get dead() {
  return this.health <= 0;
}

We'll also want a method to call when an object gets hit, since that should be the same for everything, and then a default onDeath method so our code doesn't break if we forget to add one to each child of this class.

hit() {
  this.health--;
  if(this.dead) {
    this.onDeath();
  }
}
onDeath() {}

Now we can easily set up our Player class to extend our MovementEntity and most of the logic is already there. We'll give it a custom onDeath method to randomly spawn somewhere else. And we'll also add a static method to load the image we're using for the Player. In case you don't know, a static method only exists on the class itself and not each instance of the class.

import MovementEntity from './MovementEntity';

export default class Player extends MovementEntity {
  constructor(data){
    super(data);
  }

  static preload (scene) {
    scene.load.image('ship', '/assets/player.png');
  }

  onDeath() {
    this.x = Math.random() * 512;
    this.y = Math.random() * 512;
    this.rotation = Math.random() * 360;
    this.health = 1;
  }

  update() { // This is our movement code
    if (this.inputKeys.W.isDown) {
      this.thrust(.005);
    }
    if (this.inputKeys.A.isDown) {
      this.setAngularVelocity(-.05);
    } else if (this.inputKeys.D.isDown) {
      this.setAngularVelocity(.05);
    } else {
      this.setAngularVelocity(0);
    }
  }
};

And now our Enemy class! In our constructor we need to set up a collider to check if the Enemy has run into the player. And in our preload method we need to dynamically load the enemy asset based on its color.

import Phaser from 'phaser';
import MovementEntity from './MovementEntity';

export default class Enemy extends MovementEntity {
  constructor(data){
    super(data);
    this.scene.matterCollision.addOnCollideStart({
      objectA: [this.collider],
      callback: ({ gameObjectB }) => {
        if(gameObjectB && gameObjectB.name === 'player') {
          gameObjectB.hit();
        }
      },
      context: this.scene,
    });
  }

  static preload (scene, color) {
    scene.load.image(`${color}Enemy`, `/assets/${color}Enemy.png`);
  }

  onDeath() {
    this.scene.enemies = this.scene.enemies.filter(i => i !== this);
    this.destroy();
  }

  update(player) { // This is how our enemy follows the player
    const direction = player.position.subtract(this.position);
    direction.normalize();
    this.setVelocityX(direction.x);
    this.setVelocityY(direction.y);
    this.rotation = Phaser.Math.Angle.BetweenPoints(this.position, player.position);
  }
};

Now that we have the bones of our Player and Enemy Objects, let's set them up in our scene.

I've got two images for enemy ships, pink and blue, so real quick let's add an array with that information to our scene's constructor. We're also going to want an empty array to track all the enemies in our scene, so let's set that up as well.

this.enemyColors = ['blue', 'pink'];
this.enemies = [];

In the Scene's preload method we want to call the preload methods for our Player and our Enemies. This loads the Player's image into the scene statically and the Enemie's dynamically.

preload() {
  Player.preload(this);
  this.enemyColors.forEach(color => Enemy.preload(this, color));
}

Now we need to make a Player and some Enemies. We'll save the Player to a variable so the scene can track them, and we'll add all the Enemies to the array we set up earlier.

create() {
  this.player = new Player({
    scene: this, x: 40, y: 40, texture: 'ship', name: 'player', health: 1
    });
  this.enemies.push(...this.enemyColors.map(color =>  new Enemy({
    scene: this, 
    x: Math.random() * 512, 
    y: Math.random() * 512, 
    texture: `${color}Enemy`, 
    name: `${color}Enemy`, 
    health: 2
  })));
  // This gets the movement keys for the player
  this.player.inputKeys = this.input.keyboard.addKeys('W,A,D');
}

Now that our player and our enemies are added to the scene, we just need to call their update methods in the scene's update method. Make sure to remember to call every enemy in the array.

update() {
  this.player.update();
  this.enemies.forEach(i => i.update(this.player));
}

As you can see, to use Phaser you really need to have a firm grasp on what this is doing and to really understand how ES6 PseudoClassical instantiation works. But just remember, it's all JavaScript. And learning to make simple games in Phaser 3 is fun practice for reinforcing how JavaScript behaves.

Simple OAuth2 with Passport and Express

Daniel Troyano — Sun, 09 Aug 2020 18:22:04 +0000

This tutorial is going to walk you through getting OAuth2 set up, without a database. It will just persist sessions and cookies locally using Passport and Express' built in functionality. This probably isn't ideal for production, but I found it helpful to learn, and hopefully you will too.

I'm going to use Google to log people in with OAuth2 so if you want to follow along you're going to need a Google Client ID, and Client Secret, to get that all set up you'll have to go to your Google Developer's Console.

Now before we get started, let's set up an empty package.json file with npm init -y, which will just auto select all the defaults for you. Then let's install a few modules that we're going to need.

npm install --save express express-session passport passport-google-oauth

We're using Express to write our server code, and the Express Sessions plugin will help us persist sessions. Passport is our authentication middleware, and it uses Strategies to define how it does authentication so we need Passport Google OAuth because we're using Google to log users in.

We're only going to need one file for this whole demo, so go ahead and make an index.js file. And at the top of it we're going to require all the packages we just installed.

If you want to know more about Strategies and why we're using this specific one you can check the Passport Documentation.

const express = require('express');
const session = require('express-session');
const passport = require('passport');
const GoogleStrategy = require('passport-google-oauth').OAuth2Strategy;

const app = express();

Now that we have our app initialized, we want to set up the Session and Passport middleware. Let's do Session first.

app.use(session({
  secret: 'demo',
  resave: false,
  saveUninitialized: true,
}));

I've used a secret here of a string of demo, but this should really be a secret string of random characters, but for our purposes, this is fine. ReSave and saveUninitialized are being set to essentially their default values, but if you want to know more about them and why you might want different settings, it's going to depend on how your database works, check the Express Sessions docs.

Now let's set up Passport before using it as middleware as well. We have to tell Passport how to handle serializing and deserializing a user. In our case we're just passing information along, but in a real app these will probably be a little more complicated.

passport.serializeUser((user, done) => {
  done(null, user.id);
});

passport.deserializeUser((id, done) => {
  done(null, id);
})

SerializeUser is called whenever the user logs in, and in our case it just saves the user.id to the session. Then whenever a user visits a page, deserializeUser will be called and ideally, you would use the given id to find a matching user in your database. But in our case we're just returning the id. DeserializeUser will save whatever you return to the req.user object.

Now we have to set up Passport itself, with our secrets. We also need to define a callback route, which should match the one we told Google about when we got our Client Id and Client Secret. The callbackURL is where Google is going to bounce us back to after attempting to authenticate the user.

passport.use(new GoogleStrategy({
    clientID: GOOGLE_CLIENT_ID,
    clientSecret: GOOGLE_CLIENT_SECRET,
    callbackURL: "/callback"
  },
  (accessToken, refreshToken, profile, done) => {
    return done(null, {name: profile.displayName, id: profile.id});
}));

This function is called when the user is verified and is just going to return the profile's name and id. But this is where you would parse the data you are getting back from Google. And maybe add them to your database or check to see if they already exist.

Now we just need to tell our app to use Passport.

app.use(passport.initialize());
app.use(passport.session());

And now we can set up a few routes to hit to see our app work. First let's do our '/', here we'll just console log several variables so you can see your Session become populated.

app.get('/', (req, res) => {
  console.log('SESSION',req.session);
  console.log('sessionID', req.sessionID);
  console.log('USER', req.user);
  res.status(200).send('YAY!')
});

Then we'll set up our login route which is just a call to Passport's authenticate function. We have to specify that we want to use Google, and the scope is what information we want to get back. Google has a long list of scopes you can use in their docs.

app.get('/login',
  passport.authenticate('google', { scope: ['profile']}));

We also need that callback route we were talking about earlier. Here we use authenticate as middleware, specifying Google again, and if we failed to authenticate we will redirect to our failure route. But otherwise we will redirect to our home.

app.get('/callback',
  passport.authenticate('google', { failureRedirect: '/failure'}),
  (req, res) => {
    res.redirect('/');
});

Let's also just set up that failure route, it doesn't need to do much of anything for our purposes.

app.get('/failure', (req, res) => {
  res.status(200).send('FAILED');
});

Finally let's have a logout route. Passport exposes a logout function on the request object which you can call to log out a user. So it's just as simple as you see here.

app.get('/logout', (req, res) => {
  req.logout();
  res.redirect('/');
});

Finally we have to start our app listening

app.listen(8080, () => console.log('listening'));

And that's it. You now have a very simple demo app that will talk to Google to log in a user, and then persist them in a session. Granted it won't really do anything with that user, but the goal here was just to set up the simplest possible app with some kind of authentication using Passport. I hope going through this was as helpful to other people as it was to me.

How to Setup a React Site with Parcel

Daniel Troyano — Sat, 01 Aug 2020 21:05:14 +0000

Parcel is zero configuration bundler. A bundler is something that will take your code and compile it all up for you into one file, and probably transform it in some way to make it more friendly to web browsers. Zero configuration means that once you've got parcel on your computer you just tell it to run and it just does its thing, no config file needed.

This is pretty great, especially when compared to a bundler like webpack that takes a little bit of work to set up and get running the way you want. If you want to read more about how a bundler works, or specifically webpack, check out my article on that here.

So let's talk about how to get started using Parcel.

First, let's install it globally, npm install -g parcel-bundler. Then we're going to need an empty directory to work in, so hop into one and run npm init -y to set up a package.json file. And let's grab React, cause we're using React, so run npm install --save react react-dom.

Then let's make just a basic file structure. We'll need an index.html and an index.js in our root directory and make them look like this respectively.

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>To Do List Webpack Demo</title>
</head>

<body>
  <div id="app"></div>

  <script src="./index.js"></script>
</body>

</html>

import ReactDOM from 'react-dom';
import React from 'react';
import App from './src/app';

ReactDOM.render(<App />, document.getElementById('app'));

We'll also make a really simple app.js in our src folder.

import React from 'react';

const app = () => (
  <div class="app">
    This is my React app
  </div>
);

export default app;

Then we just can just run parcel index.html in our terminal and not only will Parcel compile our app, using the given file as an entry point, but it will also start up a live updating development server for us as well!

If you notice, Parcel automatically creates a dist folder for us, where it puts all of our compiled code. If you want a different folder, you can run parcel index.html -d build, just replace build with whatever you want the folder to be called.

Parcel also natively let's you import file types beyond just Javascript. You could add import './styles.css'; to get it it to bundle your css file with your Javascript code. But you can also import things like images and Parcel will grab them up as well. So if we change our app.js to look like this.

import React from 'react';
import Puppy from './assets/puppy.jpg';

const app = () => (
  <div class="app">
    <img src={Puppy} />
    This is my React app
  </div>
);

export default app;

It will bundle up the picture of my puppy that I put in my assets folder.

But maybe the thing I like most about Parcel right out of the box is that it includes the ability to use environment variables. Go ahead and add a .env file to your root directory, it has to be adjacent to you package.json. And put some variables in it, and Parcel will let you call them with process.env.

If you don't know what an environment variable is, it's a way to keep secret things secret. Let's say you want to access your database, but you don't want the whole internet to know your password, so put it in an environment variable and that way it won't be exposed to everyone who goes to your website.

So we could put something like MY_SECRET=password12345 in our .env file. And then in our app.js we could just call process.env.MY_SECRET anytime we want access to that variable and we don't have to install any other packages or dependencies.

Parcel has a lot of cool features which you can check out at their website. And it's definitely worth taking a look at because I've just scratched the surface here, but I hope you can see the advantage of a quick and easy to use bundler that requires no configuration to work great right out of the box.

3 Ways to Upgrade your Mongoose Schemas

Daniel Troyano — Sun, 26 Jul 2020 22:09:52 +0000

So you've got your site set up with MongoDB, but you want some more functionality. So you install Mongoose, because you want a easy way to manage relationships between your data in MongoDB. Your site lets people upload Books and the Authors who write them. So your database looks a little like this.

It's not a complicated site, so you make some schemas and models using Mongoose that look like this.

const bookSchema = new mongoose.Schema({
  name: String,
  author: String,
});

const authorSchema = new mongoose.Schema({
  name: String,
});

const Author = mongoose.model('Author', authorSchema);
const Book = mongoose.model('Book', bookSchema);

Remember, Mongoose is going to create a unique _id property automatically whenever you add something to a table, so we don't need to declare it.

At this point we have two functioning tables. But they don't do a lot. If you want them to be linked, or have any cool functionality, you'd have to do it manually. But wouldn't you like to just call Book.create() with whatever you data is? Wouldn't that be nice? So let's use Mongoose's functionality to make our tables more powerful.

First, let's talk about using references and populate. Let's change our bookSchema to have a reference to our authorSchema.

const bookSchema = new mongoose.Schema({
  name: String,
  author: {
    type: mongoose.Schema.Types.ObjectId,
    ref: 'Author'
  },
});

Notice how we've changed the type to an objectId and pointed it at the Author model, so that the bookSchema knows which kind of model to populate the author field with. So now, as long as we make sure we're only putting valid Author ids in the author property on all of our Books, we can just chain a call to populate onto our finds, like this.

Book.find({}).populate('author');

We just have to tell populate what field we want to populate and it will automatically fill that field with the document it is referencing, kind of like a well written join in SQL!

Ok so now, let's say that we want to be able to track when users are adding these books to our database. But we don't want to add any code to our client side, so we have to handle it entirely with our database code.

First let's add another field to our growing schema.

const bookSchema = new mongoose.Schema({
  name: String,
  author: {
    type: mongoose.Schema.Types.ObjectId,
    ref: 'Author'
  },
  createdAt: Date
});

Did you know Mongoose has a Date type? It works pretty much just like a Javascript Date, and you can even use it to query ranges. If you want to know the specifics check out the Mongoose Docs.

So now that we have that let's add some middleware to our schema. Always make sure to add this before creating the model. There are several types of middleware that mongoose supports, but we're going to use 'save' which triggers when a new document is inserted into your database. If you want to check out the others, take a look at Mongoose's documentation.

bookSchema.pre('save', function(){
  this.createdAt = Date.now();
});

Notice our use of pre, this just means we want this to happen before we save the object. There is also 'post' middleware, which runs after the action has been done, in this case inserting the document into the table.

Then we affect any changes we want by using the keyword this to refer to the object that we are saving.

Great! Now we're adding a createdAt property to every Book that is tracking when they were added to the database.

Ok and finally I'm going to briefly touch on validators. Validators are just a shorthand way to add pre middleware to 'save' that return a boolean value. If that value is false, the document isn't added to the database, but if it returns true, everything is good and the document is inserted as expected.

Let's take a look at our Author schema and imagine that every time we add an author, we are also adding their phone number, and we need a valid phone number to add them to the database. So our new schema would look like this.

const authorSchema = new mongoose.Schema({
  name: String,
  phoneNumber: {
    type: String,
    validate: {
      validator: item => /\d{3}-\d{3}-\d{4}/.test(item),
      message: ({value}) => `${value} is not a valid phone number!`
    },
  }
});

To set up a validator, we define a validate property on our field. It needs a validator function to return a boolean that equates to the property's validity. And the message here is essentially the error message we are getting back. You can tailor this however you want, but using value like I did gives you access to the value that failed the validity test.

And that's it, we've touched on ways to give MongoDB some of the functionality of a SQL database and a few ways make schema more robust. And hopefully that's given you some ideas on how to upgrade your own Mongoose Schemas!