DEV Community: Ian Wilson

The Evolution of the AI-Driven Coder

Ian Wilson — Sun, 22 Feb 2026 21:15:24 +0000

In the past year many of us developers have evolved from being skeptical of AI tools to fully embracing them and their benefits.

For much of 2025 I wrote code the old fashioned way; getting a ticket, thinking about its requirements and what parts of the codebase I'd need to make changes in.

In some tasks, I'd need to look extra hard to ensure my changes don't impact components and services on the other side of the repo. Sure, a statically-typed language would help guide me through a lot of big refactoring. And yes test coverage is also great to have, but I'd still need to go through and do the work.

I'd need to make the updates, run the tests, fix the tests, potentially add more tests, run the linters, fix the linter issues, write a nice commit message that is helpful to whoever looks at this code later, push, make a PR, oops we need to rebase on someone else's conflicting changes, push again forcefully, and then get someone to review it.

Now, if we take into account all of these process details, on top of our daily meeting schedule, we find this job to be taxing on our energy levels.

I would always find that I came to work on Monday, refreshed after a weekend of football and drinking, and put up some modest quality work. Then Tuesday a little less, Wednesday even less, and so on. Oh I need to interview somebody? Then I'm probably not going to be able to make those UX enhancements I was hoping to get to.

The stages of letting go

Steve Yegge talks about the stages of AI assisted coding in one of his articles, Welcome to Gas Town. It starts with zero to little assistance, maybe you'd have ChatGPT running in your browser tab and you ask it about the Olympic hockey final while you do your work.

Then, you might have an agent running in your IDE, be it VSCode, Cursor, or Zed. Now the agent is co-located with your code. You gain the ability to tell it to look at certain files, highlight code snippets you want to make more concise.

Then, you find that, hey wait I can just have this robot generate entire modules. You drift from writing code to letting it write everything. Before, you were manually approving it to make updates to small chunks of code. Now, you're allowing the agent to make all changes and just looking at the diff.

The IDE becomes irrelevant. Why would you need a big editor running your myriad of LSPs, linters, and whatnot if you can just open up a terminal? The terminal agent thinks and scrolls by diffs, maybe you look at what it's doing, maybe not.

You start to think, "gee, this is pretty neat, what if I just throw this into a bunch of different tabs, each with their own agent going HAM on the codebase?" And then you do it. You might learn some growing pains along the way like how to handle multiple agents working on the same repository, but then you find out that you can use something like git worktrees.

What is a git worktree you ask? I barely understand it, but the agents do. Git is a pretty difficult interface for most humans, but the agents have been trained so much on it, they know exactly how to use it.

Then you might jump off the deep end — managing all of these agents is tiring. So you give the blank check to Anthropic and build an entire orchestrator to consume your tokens! We're cooking with gas now.

Agents unlock human agency

Concepts that you never needed to learn because you were never working at break-neck velocity are suddenly learnable.

While the agents are cranking on your work, you can learn what a git worktree is. You can prepare your lunch (they cannot do this just yet). You can jam on the guitar or play video games. All the while creating more and quite possibly better code than it would take you all of Monday.

You can use this opportunity to think more intentionally about the product, tool, or creative work you're putting together. Before, you had to ideate on implementing a solution and whether it's even the right one. Now you can go down a much abbreviated rabbit hole and find out quickly. Save some of that time and energy and fail quickly. Find out what's wrong with the approach and go back to the drawing board.

Suddenly, the number of paths available to us are immediately abundant. That side project I'd spend a couple days on and then give up? I can iterate on it from a product perspective without even looking at the code. And I can learn a new framework like SvelteKit. I've never used Supabase or Resend or Posthog but sure lets try those as well.

We are enabled to be more ambitious and focus on the outcomes that we desire.

Then we can find out if it was really the thing we wanted in the first place.

Mastering the File System with Rust

Ian Wilson — Thu, 26 Mar 2020 14:45:50 +0000

Building backend services with Rust can be difficult if you have to keep 10 tabs worth of documentation open at all times. I find it helpful to practice and learn how certain libraries work, reducing the time spent combing through documentation.

Depending on the kind of application or utility you are making, you may need to deal with the filesystem at some point.

If you're creating some sort of data storage without reaching for a database like Postgres or MySQL, you'll probably store your data in files.

If you're writing software to compose audio or video, you'd have to be able to write and read those files.

If you're creating a utility to help scaffold out a project like create-react-app or cargo new, you would want to use the filesystem to create your boilerplate directories and files.

Regardless of your goals, it would be helpful to know the common methods used in the std::fs namespace as you'll otherwise be looking them up all the time while building your project.

Overview of Key Functions

Docs: The docs for the fs crate are available here.

Reading files

Note: If you do not yet understand how generic function parameters work, you can read this chapter in the Rust Book.

For example, a path, P, is defined to be any type which implements a method which implements the trait AsRef<Path>.

Starting with the basics, this is the function signature for std::fs::read.

fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>>

You can use this method of the fs crate in order to read a file at a given path and return a vector of bytes. Its usage works like the below snippet:

use std::fs;
use std::path::Path;

fn main() {
  let path = Path::new("screenshot.png");
  let data = fs::read(path).unwrap();

  // do something with `data`
}

The read method is actually a convenience wrapper for calls to File::open and std::fs::read_to_end. This is nice because we have access to the granular, low-level functions without sacrificing the simpler read method.

pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> {
    fn inner(path: &Path) -> io::Result<Vec<u8>> {
        let mut file = File::open(path)?;
        let mut bytes = Vec::with_capacity(initial_buffer_size(&file));
        file.read_to_end(&mut bytes)?;
        Ok(bytes)
    }
    inner(path.as_ref())
}

Writing files

Here is the function signature for fs::write:

fn write<P: AsRef<Path>, C: AsRef<[u8]>>(path: P, contents: C) -> Result<()>

Assuming you have some data as a slice of bytes, you can write this to a file at a path.

Since the write method is merely a side-effect, it's return is just a Result type which resolves to either unit or an error if something went wrong.

use std::fs;
use std::path::Path;

fn main() {
  let path = Path::new("hello.txt");
  let contents = "hello there";
  fs::write(path, contents).unwrap();
}

Just like with the read method, write is a convenience wrapper for File::create and std::io::write_all. Here is the actual implementation:

pub fn write<P: AsRef<Path>, C: AsRef<[u8]>>(path: P, contents: C)
  -> io::Result<()> {
    fn inner(path: &Path, contents: &[u8]) -> io::Result<()> {
        File::create(path)?.write_all(contents)
    }
    inner(path.as_ref(), contents.as_ref())
}

With both fs::read and fs::write, we see generic type arguments in action. For the P argument, this allows us to use types like str, String, Path, or PathBuf when calling one of these methods.

The standard library uses a pattern where they define an inner function with specific type parameters. They then call it with the outermost arguments after casting them with as_ref, the function required by the AsRef trait.

My goal is not to explain generic types and traits, but I find exploring how the standard library uses them to be quite insightful.

An Example: Copying files

Let us say we'd like to copy a file from one directory to another, similar to the cp command on unix.

We could do this by writing:

use std::fs;
use std::path::Path;

fn main() {
  let input = Path::new("hello.txt");
  let data = fs::read(input).unwrap();

  let output = Path::new("hello_copy.txt");
  fs::write(output, data).unwrap();
}

Rust's fs library gives us yet another convenience method for this task, fs::copy.

use std::fs;
use std::path::Path;

fn main() {
  let input = Path::new("hello.txt");
  let output = Path::new("hello_copy.txt");
  fs::copy(input, output).unwrap();
}

Other Useful Methods

Read and write are definitely some of the more obvious uses of a filesystem, but generally speaking, a thorough application will also include other capabilities like handling directories.

Reading utilities:

fs::read_to_string - returns file contents as a String rather than [u8] bytes
fs::read_dir - returns an iterator over all of the entries (files and other directories) within a directory

Writing utilities:

fs::create_dir - creates a new, empty directory at a given path.
fs::create_dir_all - given a path, will recursively create all necessary directories if they are missing
fs::rename - rename a file or directory to a given name, similar to mv command in unix

Removal utilities:

fs::remove_file - remove a given file
fs::remove_dir - remove a given, empty directory
fs::remove_dir_all - remove a directory and all of its contents (be careful with this one)

Since this isn't a match statement, I won't present an exhaustive list of methods, but you can view that in the docs.

Thanks For Reading

I hope you have enjoyed this article or found some sort of use for it. I am currently working on a project that uses some of these method to create something that will help my own development.

If you'd like to keep up with the next time I drop an article in the realm of Rust, ReasonML, GraphQL, or software development at large, feel free to give me a follow on Twitter, dev.to, or on my website at ianwilson.io.

Breaking Out of a Rut or Creative Block

Ian Wilson — Wed, 08 Jan 2020 06:34:30 +0000

Creative professions can be great fun when you're in rhythm. In this state, the ideas emanate from your fingertips. When you're productive: you're hitting your deadlines.

You push metal at the gym, clean your room, and beat the Elite 4. You're the unstoppable force that will build the next unicorn.

But then things take a turn. You have personal stresses at home like a breakup or a fatal pet emergency. You suffer an injury while lifting weights or downhill mountain biking. Your mojo vanishes, even for no clear reason at all — it happens to everyone.

Recently, I experienced a rut. It is a total lack of energy to do anything beside drink beer and watch all the Austin Powers movies. Not the worst fate, I will add, but I would like to do other things too.

To break out, I employed strategies that would help anyone whether you've been out of it for a single day or 6 months.

Action Yields Action

Consider the how you might try to break out of a writers block. I wrote my last article on September 13, 2019, with the goal to continue writing articles. Every week, I would write about fantastic programming topics like Rust or ReasonML.

Now it's 2020, and I'm writing the next one since then. I've had the intent to write something on my mind almost every day for the past several months but I never did it.

I sat down, wrote those first two sentences you can see above, and then vacuumed my living room.

And then, I wrote the rest of it.

My point is, the simple act of scribbling those two sentences spawned a flurry of motivation. By writing two sentences, I had convinced myself that I could do it.

I always knew I could because I had written plenty of articles before. But subconsciously, I could not execute.

I had created the inspiration that it would be possible to write this post. That inspiration led to motivation to continue writing, thus leading to more writing. That is the action which is our real goal here.

Watch a motivational speaker or a Get-Rich-Quick guru. You may come away with the feeling of inspiration.

"Wow look at these people, they are so rich and so inspiring!", you think. The crowd applauds until the final sales pitch, when they file out of the room.

After you get home, then what? Flip on Netflix, after all, seeing those people was stressful and now its time to relax. Even though that presentation (or video, or book...) was inspiring, it does not always spur the action that will get you to where you want to be.

Make a simple move towards where you want to be, and then dwell on it. Be proud of that effort, because it is proof that you can do it.

Try Not to Go All-In

Let us suppose you put in a little action and now you have more energy and motivation than you know what to do with. What now? While you could try to exhaust all of it in one sitting, I advise against this.

It is more effective to be increasing in productivity day by day rather than blow it over a short period. A single burst of activity will sound cool. You can show off how productive you were that one day, but consider the trade-offs.

If you do too much, you force your brain to think you'll be working this hard every day.
If you use all of your energy, you may lead yourself right back into a rut when you're mentally exhausted the next day.
If you have a full time job and you want to balance it with exercise, family, friends, and whatever other priorities you have... take it easy.

My suggestion is to start with small wins; a couple sentences, a new function/class, a single song on a guitar. When you've completed a simple action, the rest will follow.

After you've been working at it for 20-50 minutes, take a break and reflect on what you accomplished. You can continue for another period of time, or you can trust the same technique to help you carry on tomorrow.

Savor your victories today. The next ones will be bigger and even more rewarding. The goal is consistency.

Smaller, Yet Effective Tips

Here are a few little tips I can offer up to get you out of the rut.

Eat well. I've had a pretty big boost in energy with Athletic Greens after I saw it mentioned on Tim Ferriss's show. They don't sponsor me but there's a ton of benefit for getting your full daily quota of veggies right away. Its part of my excuse to eat whatever else I'd like that day.
Don't overeat when you go out, save your leftovers. When I go out, I prefer pasta since I know it will also taste good later. Meal planned.
Cleaning your living space has a tremendous effect on what you feel you can accomplish.
Exercise often, but not too hard! I run a lot, but I am much more depleted throughout the day/week when I spent too much time around 90% of my maximum heart rate. If you exercise after work, understand that being mentally exhausted will affect your perceived effort.

I usually post articles that are heavy on the technical side. If you're interested in ReasonML or Rust, definitely check out my other works.

If you came here to get out of a rut, then I hope a little action helps lift you out.

Thanks for reading, and see you next time!

Building Powerful GraphQL Servers with Rust

Ian Wilson — Fri, 13 Sep 2019 09:39:07 +0000

Photo by Bill Oxford on Unsplash

Setting up a GraphQL server with Rust, Juniper, Diesel, and Actix; learning about Rust's web frameworks and powerful macros along the way.

Source Code: github.com/iwilsonq/rust-graphql-example

Serving applications via GraphQL is quickly becoming the easiest and most effective way to deliver data to clients. Whether you're on a mobile device or a browser, it provides the data requested and nothing more.

Client applications no longer need to stitch together information from separate data sources. GraphQL servers are in charge of the integration, eliminating the need for excess data and round-trip requests for data.

Of course, this implies that the server has to handle aggregating data from different sources, such as home-owned backend services, databases, or third party APIs. This may be resource intensive, how can we optimize for CPU time?

Rust is a marvel of a language, pairing the raw performance of a low level language like C with the expressiveness of modern languages. It emphasizes type and memory safety, especially when there are potentially data races in concurrent operations.

Let us see what goes into building a GraphQL server with Rust. We are going to learn about

Juniper GraphQL Server
Actix web framework integrated with Juniper
Diesel for quering a SQL database
Useful Rust macros and derived traits for working with these libraries

Note that I will not go into detail regarding installing Rust or Cargo. This article assumes some preliminary knowledge of the Rust toolchain.

Setting up an HTTP Server

To begin, we need to initialize our project with cargo and then install dependencies.

    cargo new rust-graphql-example
    cd rust-graphql-example

The initialization command bootstraps our Cargo.toml file which contains our projects dependencies as well as a main.rs file which has a simple "Hello World" example.

    // main.rs

    fn main() {
      println!("Hello, world!");
    }

As a sanity check, feel free to run cargo run in order to execute the program.

Installing the necessary libraries in Rust means adding a line containing the library name and version number. Let's update the dependencies sections of Cargo.toml like so:


    # Cargo.toml

    [dependencies]
    actix-web = "1.0.0"
    diesel = { version = "1.0.0", features = ["postgres"] }
    dotenv = "0.9.0"
    env_logger = "0.6"
    futures = "0.1"
    juniper = "0.13.1"
    serde = "1.0"
    serde_derive = "1.0"
    serde_json = "1.0"

This article will cover implementing a GraphQL server using Juniper as the GraphQL library and Actix as the underlying HTTP server. Actix has a very nice API and works well with the stable version of Rust.

When those lines are added, the next time the project compiles it will include those libraries. Before we compile, lets update main.rs with a basic HTTP server, handling the index route.

    // main.rs
    use std::io;

    use actix_web::{web, App, HttpResponse, HttpServer, Responder};

    fn main() -> io::Result<()> {
        HttpServer::new(|| {
            App::new()
                .route("/", web::get().to(index))
        })
        .bind("localhost:8080")?
        .run()
    }

    fn index() -> impl Responder {
        HttpResponse::Ok().body("Hello world!")
    }

The first two lines at the top bring the module we need into scope. The main function here returns an io::Result type, which allows us to use the question mark as a shorthand for handling results.

The server's routing and configuration is created in the instance of App, which is created in a closure provided by the HTTP server's constructor.

The route itself is handled by the index function, whose name is arbitrary. As long as this function properly implements Responder it can be used as the parameter for the GET request at the index route.

If we were writing a REST API, we could proceed with adding more routes and associated handlers. We will see soon that we are trading a listing of route handlers for objects and their relations.

Now we will introduce the GraphQL library.

Creating the GraphQL Schema

At the root of every GraphQL schema is a root query. From this root we can query lists of objects, specific objects, and whatever fields they might contain.

Call this the QueryRoot, and we shall denote it with the same name in our code. Since we are not going to be setting up a database or any third party APIs, we'll be hard-coding the little data we have here.

To add a little color to this example, the schema will depict a generic list of members.

Under src, add a new file called graphql_schema.rs along with the following contents:

    // graphql_schema.rs
    use juniper::{EmptyMutation, RootNode};

    struct Member {
      id: i32,
      name: String,
    }

    #[juniper::object(description = "A member of a team")]
    impl Member {
      pub fn id(&self) -> i32 {
        self.id  
      }

      pub fn name(&self) -> &str {
        self.name.as_str()
      }
    }

    pub struct QueryRoot;

    #[juniper::object]
    impl QueryRoot {
      fn members() -> Vec<Member> {
        vec![
          Member {
            id: 1,
            name: "Link".to_owned(),
          },
          Member {
            id: 2,
            name: "Mario".to_owned(),
          }
        ]
      }
    }

Along with our imports, we define our first GraphQL object in this project, the member. They are simple beings, with an id and name. We'll think about more complicated fields and patterns later.

After stubbing out the QueryRoot type as a unit struct, we get to define the field itself. Juniper exposes a Rust macro called object which allows us to define fields on the different nodes throughout our schema. For now, we only have the QueryRoot node, so we'll expose a field called members on it.

Rust macros often have an unusual syntax compared to standard functions. They don't merely take some arguments and produce a result, they expand into much more complex code at compile time.

Exposing the Schema

Below our macro call to create the members field, we will define the RootNode type that we expose on our schema.

    // graphql_schema.rs

    pub type Schema = RootNode<'static, QueryRoot, EmptyMutation<()>>;

    pub fn create_schema() -> Schema {
      Schema::new(QueryRoot {}, EmptyMutation::new())
    }

Because of the strong typing in Rust, we are forced to provide the mutation object argument. Juniper exposes an EmptyMutation struct for just this occasion, that is, when we want to create a read-only schema.

Now that the schema is prepared, we can update our server in main.rs to handle the "/graphql" route. Since having a playground is also nice, we'll add a route for GraphiQL, the interactive GraphQL playground.

    // main.rs
    #[macro_use]
    extern crate juniper;

    use std::io;
    use std::sync::Arc;

    use actix_web::{web, App, Error, HttpResponse, HttpServer};
    use futures::future::Future;
    use juniper::http::graphiql::graphiql_source;
    use juniper::http::GraphQLRequest;

    mod graphql_schema;

    use crate::graphql_schema::{create_schema, Schema};

    fn main() -> io::Result<()> {
        let schema = std::sync::Arc::new(create_schema());
        HttpServer::new(move || {
            App::new()
                .data(schema.clone())
                .service(web::resource("/graphql").route(web::post().to_async(graphql)))
                .service(web::resource("/graphiql").route(web::get().to(graphiql)))
        })
        .bind("localhost:8080")?
        .run()
    }

You'll notice I've specified a number of imports that we will be using, including the schema we've just created. Also see that:

we call create_schema inside an Arc (atomically reference counted), to allow shared immutable state across threads (cooking with 🔥 here I know)
we mark the closure inside HttpServer::new with move, indicating that the closure takes ownership of the inner variables, that is, it gains a copy of schema
schema is passed to the data method indicating that it is to be used inside the application as shared state between the two services

We must now implement the handlers for those two services. Starting with the "/graphql" route:

    // main.rs

    // fn main() ...

    fn graphql(
        st: web::Data<Arc<Schema>>,
        data: web::Json<GraphQLRequest>,
    ) -> impl Future<Item = HttpResponse, Error = Error> {
        web::block(move || {
            let res = data.execute(&st, &());
            Ok::<_, serde_json::error::Error>(serde_json::to_string(&res)?)
        })
        .map_err(Error::from)
        .and_then(|user| {
            Ok(HttpResponse::Ok()
                .content_type("application/json")
                .body(user))
        })
    }

Our implementation of the "/graphql" route takes executes a GraphQL request against our schema from application state. It does this by creating a future from web::block and chaining handlers for success and error states.

Futures are analogous to Promises in JavaScript, which is enough to understand this code snippet. For a greater explanation of Futures in Rust, I recommend this article by Joe Jackson.

In order to test out our GraphQL schema, we'll also add a handler for "/graphiql".

    // main.rs

    // fn graphql() ...

    fn graphiql() -> HttpResponse {
        let html = graphiql_source("http://localhost:8080/graphql");
        HttpResponse::Ok()
            .content_type("text/html; charset=utf-8")
            .body(html)
    }

This handler is much simpler, it merely returns the html of the GraphiQL interactive playground. We only need to specify which path is serving our GraphQL schema, which is "/graphql" in this case.

With cargo run and navigation to http://localhost:8080/graphiql, we can try out the field we configured.

It does seem to take a little more effort than setting up a GraphQL server with Node.js and Apollo but the static typing of Rust combined with its incredible performance makes it a worthy trade — if you're willing to work at it.

Setting up Postgres for Real Data

If I stopped here, I wouldn't even be doing the examples in the docs much justice. A static list of two members that I wrote myself at dev time will not fly in this publication.

Installing Postgres and setting up your own database belongs in a different article, but I'll walk through how to install diesel, the popular Rust library for handling SQL databases.

See here to install Postgres locally on your machine. You can also use a different database like MySQL in case you are more familiar with it.

The diesel CLI will walk us through initializing our tables. Let's install it:

    cargo install diesel_cli --no-default-features --features postgres

After that, we will add a connection URL to a .env file in our working directory:

    echo DATABASE_URL=postgres://localhost/rust_graphql_example > .env

Once that's there, you can run:

    diesel setup

    # followed by

    diesel migration generate create_members

Now you'll have a migrations folder in your directory. Within it, you'll have two SQL files: one up.sql for setting up your database, the other down.sql for tearing it down.

I will add the following to up.sql:

    CREATE TABLE teams (
      id SERIAL PRIMARY KEY,
      name VARCHAR NOT NULL
    );

    CREATE TABLE members (
      id SERIAL PRIMARY KEY,
      name VARCHAR NOT NULL,
      knockouts INT NOT NULL DEFAULT 0,
      team_id INT NOT NULL,
      FOREIGN KEY (team_id) REFERENCES teams(id)
    );

    INSERT INTO teams(id, name) VALUES (1, 'Heroes');
    INSERT INTO members(name, knockouts, team_id) VALUES ('Link', 14, 1);
    INSERT INTO members(name, knockouts, team_id) VALUES ('Mario', 11, 1);
    INSERT INTO members(name, knockouts, team_id) VALUES ('Kirby', 8, 1);

    INSERT INTO teams(id, name) VALUES (2, 'Villains');
    INSERT INTO members(name, knockouts, team_id) VALUES ('Ganondorf', 8, 2);
    INSERT INTO members(name, knockouts, team_id) VALUES ('Bowser', 11, 2);
    INSERT INTO members(name, knockouts, team_id) VALUES ('Mewtwo', 12, 2);

And into down.sql I will add:

    DROP TABLE members;
    DROP TABLE teams;

If you've written SQL in the past, these statements will make some sense. We are creating two tables, one to store teams and one to store members of those teams.

I am modeling this data based on Smash Bros if you have not yet noticed. It helps the learning stick.

Now to run the migrations:

    diesel migration run

If you'd like to verify that the down.sql script works to destroy those tables, run: diesel migration redo.

Now the reason why I named the GraphQL schema file graphql_schema.rs instead of schema.rs, is because diesel overwrites that file in our src direction by default.

It keeps a Rust macro representation of our SQL tables in that file. It is not so important to know how exactly this table! macro works, but try not to edit this file — the ordering of the fields matters!

    // schema.rs (Generated by diesel cli)

    table! {
        members (id) {
            id -> Int4,
            name -> Varchar,
            knockouts -> Int4,
            team_id -> Int4,
        }
    }

    table! {
        teams (id) {
            id -> Int4,
            name -> Varchar,
        }
    }

    joinable!(members -> teams (team_id));

    allow_tables_to_appear_in_same_query!(
        members,
        teams,
    );

Finally, thanks to a comment, we'll want to import diesel and expose the schema module in main.rs:


    #[macro_use]
+   extern crate diesel;
    extern crate juniper;

    use std::io;
    use std::sync::Arc;

    use actix_web::{web, App, Error, HttpResponse, HttpServer};
    use futures::future::Future;
    use juniper::http::graphiql::graphiql_source;
    use juniper::http::GraphQLRequest;

    mod graphql_schema;
+   mod schema;

    use crate::graphql_schema::{create_schema, Schema};

Wiring up our Handlers with Diesel

In order to serve the data in our tables, we must first update our Member struct with the new fields:

// graphql_schema.rs

+ #[derive(Queryable)]
pub struct Member {
  pub id: i32,
  pub name: String,
+ pub knockouts: i32,
+ pub team_id: i32,
}

#[juniper::object(description = "A member of a team")]
impl Member {
  pub fn id(&self) -> i32 {
    self.id  
  }

  pub fn name(&self) -> &str {
    self.name.as_str()
  }

+ pub fn knockouts(&self) -> i32 {
+   self.knockouts
+ }

+ pub fn team_id(&self) -> i32 {
+   self.team_id
+ }
}

Note that we are also adding the Queryable derived attribute to Member. This tells Diesel everything it needs to know in order to query the right table in Postgres.

Additionally, add a Team struct:

    // graphql_schema.rs

    #[derive(Queryable)]
    pub struct Team {
      pub id: i32,
      pub name: String,
    }

    #[juniper::object(description = "A team of members")]
    impl Team {
      pub fn id(&self) -> i32 {
        self.id
      }

      pub fn name(&self) -> &str {
        self.name.as_str()
      }

      pub fn members(&self) -> Vec<Member> {
        vec![]
      }
    }

In a short while, we will update the members function on Team to return a database query. But first, let us add a root call for members.

    // graphql_schema.rs
    + extern crate dotenv;

    + use std::env;

    + use diesel::pg::PgConnection;
    + use diesel::prelude::*;
    + use dotenv::dotenv;
    use juniper::{EmptyMutation, RootNode};

    + use crate::schema::members;

    pub struct QueryRoot;

    +  fn establish_connection() -> PgConnection {
    +    dotenv().ok();
    +    let database_url = env::var("DATABASE_URL").expect("DATABASE_URL must be set");
    +    PgConnection::establish(&database_url).expect(&format!("Error connecting to {}", database_url))
    +  }

    #[juniper::object]
    impl QueryRoot {
      fn members() -> Vec<Member> {
    -   vec![
    -     Member {
    -       id: 1,
    -       name: "Link".to_owned(),
    -     },
    -     Member {
    -       id: 2,
    -       name: "Mario".to_owned(),
    -     }
    -   ]
    +   use crate::schema::members::dsl::*;
    +   let connection = establish_connection();
    +   members
    +     .limit(100)
    +     .load::<Member>(&connection)
    +     .expect("Error loading members")
      }
    }

Very good, we have our first usage of a diesel query. After initializing a connection, we use the members dsl, which is generated from our table! macros in schema.rs, and call load, indicating that we wish to load Member objects.

Establishing a connection means connecting to our local Postgres database by using the env variable we declared earlier.

Assuming that was all input correctly, restart the server with cargo run, open GraphiQL and issue the members query, perhaps adding the two new fields.

The teams query will be very similar — the difference being we must also add a part of the query to the members function on the Team struct in order to resolve the relationship between GraphQL types.

    // graphql_schema.rs

    #[juniper::object]
    impl QueryRoot {
      fn members() -> Vec<Member> {
        use crate::schema::members::dsl::*;
        let connection = establish_connection();
        members
          .limit(100)
          .load::<Member>(&connection)
          .expect("Error loading members")
      }

    +  fn teams() -> Vec<Team> {
    +    use crate::schema::teams::dsl::*;
    +    let connection = establish_connection();
    +    teams
    +      .limit(10)
    +      .load::<Team>(&connection)
    +      .expect("Error loading teams")
    +  }
    }

    // ...

    #[juniper::object(description = "A team of members")]
    impl Team {
      pub fn id(&self) -> i32 {
        self.id
      }

      pub fn name(&self) -> &str {
        self.name.as_str()
      }

      pub fn members(&self) -> Vec<Member> {
    -    vec![]
    +    use crate::schema::members::dsl::*;
    +    let connection = establish_connection();
    +    members
    +      .filter(team_id.eq(self.id))
    +      .limit(100)
    +      .load::<Member>(&connection)
    +      .expect("Error loading members")
      }
    }

When running this is GraphiQL, we get:

I really like the way this is turning out, but there is one more thing we must add in order to call this tutorial complete.

The Create Member Mutation

What good is a server if it is read-only and not writable? Well I'm sure those have their uses too, but we would like to write data to our database, how hard can it be?

First we'll create a MutationRoot struct that will eventually replace our usage of EmptyMutation. Then we will add the diesel insertion query.

    // graphql_schema.rs

    // ...

    pub struct MutationRoot;

    #[juniper::object]
    impl MutationRoot {
      fn create_member(data: NewMember) -> Member {
        let connection = establish_connection();
        diesel::insert_into(members::table)
          .values(&data)
          .get_result(&connection)
          .expect("Error saving new post")
      }
    }

    #[derive(juniper::GraphQLInputObject, Insertable)]
    #[table_name = "members"]
    pub struct NewMember {
      pub name: String,
      pub knockouts: i32,
      pub team_id: i32,
    }

As GraphQL mutations typically go, we define an input object called NewMember and make it the argument of the create_member function. Inside this function, we establish a connection and call the insert query on the members table, passing the entire input object.

It is super convenient that Rust allows us to use the same structs for GraphQL input objects as well as Diesel insertable objects.

Let me make this a little more clear, for the NewMember struct:

we derive juniper::GraphQLInputObject in order to create a input object for our GraphQL schema
we derive Insertable in order to let Diesel know that this struct is valid input for an insertion SQL statement
we add the table_name attribute so that Diesel knows which table to insert it in

There is a lot of magic going on here. This is what I love about Rust, it has great performance but the code has features like macros and derived traits to abstract away boilerplate and add functionality.

Finally, at the bottom of the file, add the MutationRoot to the schema:

    // graphql_schema.rs

    pub type Schema = RootNode<'static, QueryRoot, MutationRoot>;

    pub fn create_schema() -> Schema {
      Schema::new(QueryRoot {}, MutationRoot {})
    }

I hope that everything is there, we can test out all of our queries and mutations thus far now:

    # GraphiQL

    mutation CreateMemberMutation($data: NewMember!) {
      createMember(data: $data) {
        id
        name
        knockouts
        teamId
      }
    }

    # example query variables
    # {
    #   "data": {
    #     "name": "Samus",
    #     "knockouts": 19,
    #     "teamId": 1
    #   }
    # }

If that mutation ran successfully, you can pop open a bottle of champagne as you are on your way to building performant and type-safe GraphQL Servers with Rust.

Thanks For Reading

I hope you have enjoyed this article, I also hope that it gave you some sort of inspiration for your own work.

The source code is here github.com/iwilsonq/rust-graphql-example.

ReasonML with React Hooks Tutorial — Building a Pomodoro Timer

Ian Wilson — Mon, 15 Apr 2019 06:37:20 +0000

Source code available on github

ReasonML is a programming language that combines the simplicity of JavaScript with the performance of OCaml. JavaScript programmers should give ReasonML a try. Reason inherits OCaml's typesystem as well as the approachability of JavaScript.

With ReasonReact and BuckleScript, we can compile Reason code to JavaScript that works like good old React.

But that's not all, things are getting even better for the Reason ecosystem. Earlier last week, ReasonReact version 0.7.0 dropped, with support for React hooks. We can now build robust components with React hooks that:

eliminate duplicated lifecycle logic (like in componentDidMount, componentDidUpdate, and componentWillUnmount)
eliminate the need for complicated patterns like higher-order components or render props
allow easier refactoring of stateful components

Think for a moment about that last point, what else give us easier refactorability?

A rock solid typesystem and a helpful compiler!

Today, we're going to build a Pomodoro Timer like this using Reason and React.

A pomodoro timer allows you to set a timer for say 25 or 30 minutes that lets you know when to stop working. Because sometimes taking a break is good, and you better believe I'm using one while writing this.

Initializing a Project

The first step is to install BuckleScript, a tool that will compile our Reason code to JavaScript.

npm install -g bs-platform

After that, we can scaffold our project with the init command, and setting the theme to react-hooks.

bsb -init pomodoro-timer -theme react-hooks
cd pomodoro-timer && npm install

Now that our project set up, we can mention our folder layout. Our Reason code belongs in the src directory. Where we usually have an index.js file in a JavaScript React project, we have an Index.re file. These files serve the same purpose: render the app root.

Since our code will compile to JavaScript, I still like to have a bundler like Webpack to bundle those files.

Tip: It is generally considered a best practice to keep your folder structure as flat as possible with ReasonML, using captialized file names (like Timer.re). See the Reason [docs](https://reasonml.github.io/docs/en/project-structure#folders) for a discussion on project structure.

Running the code

Before I clean up the environment, let us try running the code. This will need two or three separate terminal tabs:

# in one tab
npm start

This runs bsb -make-world -w which compiles your Reason files on every change. It does this quickly, mind you.

# in another tab
npm run webpack

This command takes our compiled JavaScript and spits out a bundle that we can then open in a browser using:

open build/index.html

I prefer use a static file server like zeit/serve.

# install `serve` globally
npm i -g serve

# serve it!
serve build/

Cleaning up the Environment

I want to clean up the default project structure before writing an implementation.

Remove the Component1.re and Component2.re files, we will not be using these. You can still read them and try to making sense of how hooks are working in our new environment.
Replace index.html with the following:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Pomodoro Timer</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="Index.js"></script>
  </body>
</html>

Replace Index.re with the following:

ReactDOMRe.renderToElementWithId(<Timer />, "root");

Open up bsconfig.json and change the field "in-source" from true to false. This will output our compiled JavaScript into the lib/js directory. I prefer this over leaving them inside of our root src directory.
Tell webpack to build from the new location by changing webpack.config.js to the following:

module.exports = {
  entry: './lib/js/src/Index.bs.js',
  // rest of webpack config
}

And now with all out that taken care of, we can begin the fun part, the implementation.

Building a Stateless Component

After cleaning up, notice that we are trying to render a Timer component but we have not even defined one. Let us write a stateless component to render to the page.

[@react.component]
let make = () => {
  <div> {ReasonReact.string("One day this will be a timer")} </div>;
};

I want to highlight how simple this code is. Writing a stateless React component in the previous version was more verbose:

/* DO NOT WRITE THIS */
let component = ReasonReact.statelessComponent("Timer");
let make = () => {
  ...component,
  render: _children =>  <div> {ReasonReact.string("One day this will be a timer")} </div>;
};

Even compared to regular JavaScript with React, this new syntax is incredibly slick. With Reason projects, we do not need to layer imports on top of the file every time we make a new file.

The useReducer Hook

Now we are going to introduce some state into this equation. We do not have any "class" components, we are still using functional components. But now we are going to use React hooks to compose a solution.

For our timer, we need to keep track of at least two things:

The seconds on the clock
Whether it is ticking or not

When we consider any timer, we usually have three buttons: Start, Stop, and Reset. These map to directly to user interactions, but there is one more: the Tick itself. Even though the tick is not controlled by the user, it is still an action that should return a new state for our reducer.

At the top of Timer.re, where we will build this whole app, add the following:

type state = {
  seconds: int,
  isTicking: bool
};

type action =
  | Start
  | Stop
  | Reset
  | Tick;

How easy it is, to implement an application after you have described your states needs and actions!

Next we'll update our make function to use a reducer:

[@react.component]
let make = () => {
  let (state, dispatch) =
    React.useReducer(
      (state, action) =>
        switch (action) {
        | Start => {...state, isTicking: true}
        | Stop => {...state, isTicking: false}
        | Reset => {...state, seconds: 30}
        | Tick => {...state, seconds: state.seconds - 1}
        },
      {isTicking: false, seconds: 30},
    );

  <div>
    {ReasonReact.string(
       "There are " ++ string_of_int(state.seconds) ++ " on the clock",
     )}
  </div>;
};

The syntax is like that of ReactJS. The useReducer function returns a tuple as opposed an array. This is because JavaScript does not know what the heck a tuple is. We make sure to handle each of our action types inside this reducer, returning a whole copy of the state.

The second argument to useReducer is the initial state of the reducer. It would make sense for the time to receive the initial time as a prop but I'll leave it this way for now.

Now we need a way to invoke these actions. Let us start with the Tick because it is the most complicated bit.

The useEffect hook

To update the timer every second, we need to create an effect. In the JavaScript world, this means putting a callback function within setInterval.

Let us add this hook between the useReducer function and the returned JSX.

React.useEffect0(() => {
  let timerId = Js.Global.setInterval(() => dispatch(Tick), 1000);
  Some(() => Js.Global.clearInterval(timerId));
});

If you recall the way useEffect works:

The first argument is a callback function that runs when the component mounts, updates, or unmounts.
Optionally, the callback function can return another function that performs cleanup. This includes unsubscribing from sockets or clearing a setInterval so it does not persist forever.

If you run the code and refresh your browser, you'll see that our timer is going to run indefinitely.

It should not do this, so lets update our reducer again to account for whether the isTicking flag is true or false. We will also make sure that seconds are greater than zero so we do not go negative.

let (state, dispatch) =
    React.useReducer(
      (state, action) =>
        switch (action) {
        | Start => {...state, isTicking: true}
        | Stop => {...state, isTicking: false}
        | Reset => {...state, seconds: 30}
        | Tick => state.isTicking && state.seconds > 0
            ? {...state, seconds: state.seconds - 1} : state
        },
      {isTicking: false, seconds: 30},
    );

Now you can verify this by setting isTicking to true and seconds to 3. Lovely, this app is functional now. If you wanted to actually use it, refresh your browser and watch it count down.

Interactivity with Buttons

To make this Timer even better, I am going to add buttons.

Let us define a Button module in the same file as our Timer, right above the make function.

module Button = {
  [@react.component]
  let make = (~label, ~onClick) => {
    <button onClick> {label |> ReasonReact.string} </button>;
  };
};

This button takes a label and an onClick prop. We can add them to our Timer, at the bottom of the make function like so:

[@react.component]
let make = () => {
  /* useReducer */

  /* useEffect0 */

  <div>
      {ReasonReact.string(
        "There are " ++ string_of_int(state.seconds) ++ " seconds on the clock",
      )}
      {state.isTicking
        ? <Button label="STOP" onClick={_event => dispatch(Stop)} />
        : <>
            <Button label="START" onClick={_event => dispatch(Start)} />
            <Button label="RESET" onClick={_event => dispatch(Reset)} />
          </>}
    </div>;
};

Try running this in your browser, you should see:

If you click START, it will start. If you click STOP it will stop. RESET will bring the timer back up to the initial time. Pretty straightforward how it just works!

At this point, our app is feature-complete. Read on to make it even cooler, with style and other aesthetic details.

Aesthetic Concerns

Let us add some styles and make this timer look pretty. Or at least better.

Update the JSX in Timer to the following:

[@react.component]
let make = () => {
  /* useReducer */

  /* useEffect0 */
<div
    style={ReactDOMRe.Style.make(
      ~border="1px solid black",
      ~borderRadius="8px",
      ~maxWidth="180px",
      ~textAlign="center",
      (),
    )}>
    <p
      style={ReactDOMRe.Style.make(
        ~color="#444444",
        ~fontSize="42px",
        ~margin="16px 0",
        (),
      )}>
      {state.seconds |> formatTime |> ReasonReact.string}
    </p>
    {state.isTicking
       ? <Button label="STOP" onClick={_event => dispatch(Stop)} />
       : <>
           <Button label="START" onClick={_event => dispatch(Start)} />
           <Button label="RESET" onClick={_event => dispatch(Reset)} />
         </>}
  </div>;
};

I have introduced the default styles that come with ReasonReact. They are not my preferred style solution as I like bs-css better, but for this small project, they will do fine.

I also introduce a formatTime function. Let us implement that function so our project compiles:

let padNumber = numString =>
  if (numString |> int_of_string < 10) {
    "0" ++ numString;
  } else {
    numString;
  };

let formatTime = seconds => {
  let mins = seconds / 60;
  let minsString = mins |> string_of_int |> padNumber;
  let seconds = seconds mod 60;
  let secondsString = seconds |> string_of_int |> padNumber;
  minsString ++ ":" ++ secondsString;
};

I included padNumber as well, a useful utility that pads minutes and seconds which are less than 10. This makes the timer more reader friendly.

I will be honest, this timer looks pretty good right now and I have not even styled the buttons. I will leave that as a task for the reader if they are so inclined.

Update the Document Title

The concept of a timer in the browser can be further improved. If we have the time remaining persist in the browser tab itself, it would be visible if the user is in another tab.

All we have to do to get that going is update our Tick action in the reducer. I'll even show off ReasonML's interop with JavaScript by updating the document title. Note the %bs.raw directive, this allows us to put on the JavaScript training wheels and use it directly.

let updateTitle: string => unit = [%bs.raw
  {|
  function updateTitle(remaining) {
    document.title = "⏰ " + remaining + " ⏰";
  }|}
];

[@react.component]
let make = () => {
let (state, dispatch) =
    React.useReducer(
      (state, action) =>
        switch (action) {
        | Start => {...state, isTicking: true}
        | Stop => {...state, isTicking: false}
        | Reset => {...state, seconds: 30}
        | Tick =>
          state.isTicking && state.seconds > 0
            ? {
              updateTitle(formatTime(state.seconds - 1));
              {...state, seconds: state.seconds - 1};
            }
            : state
        },
      {isTicking: false, seconds: 30},
    );

/* useEffect0 */


/* JSX return */
};

And with that, I am finished with the implementation of the timer:

Summary

With this tutorial we tackled the updated ReasonReact syntax with React hooks. when React hooks dropped late last year I could not wait to be able to use them in Reason projects. Now that they are here, we can take advantage of strong typed, composable, functional code.

We learned:

how to make a basic stateless component
how to use the useReducer hook
how to use the useEffect hook
how to define other React components in the same file/module.
how to use basic styles in ReasonReact
how to do interop with %bs.raw

I hope this has been a fun or useful experience, be sure to follow me @iwilsonq on dev.to, Twitter, Medium or anywhere else I roam.

If you want to how ReasonML works seamlessly with GraphQL, check out this article I wrote on ReasonML with GraphQL:

ReasonML with GraphQL, the Future of Type-Safe Web Applications

Ian Wilson ・ Mar 13 '19

#reason #graphql #javascript #functional

If you'd like to keep up with future posts, sign up for my newsletter here!

The Edge, Wit, and Courage of ReasonML

Ian Wilson — Fri, 22 Mar 2019 07:47:27 +0000

Photo by Donald Chodeva on Unsplash

ReasonML has stolen my attention recently.

If I'm not at work or running about, I am probably digging into some ReasonML/OCaml repositories like an addict in the tenderloin.

Perhaps I like it for the unparalleled incremental build speed.

Perhaps I like it because its not too different from JavaScript yet it nets me a plethora of built-in advantages like type safety.

Perhaps I like it because of my affinity for math in school, and the functional paradigm gives me a warm fuzzy feeling inside.

There are a few reasons, no pun intended, for my love of Reason. Just like a functional program wields function composition with immutable state to achieve its goal, Reason's composition of the best of OCaml and JavaScript make it a strong candidate for the future of programming.

The Edge of OCaml

For starters, Reason is basically a syntax upgrade to OCaml. Let me start by describing how that helps us.

Speed

OCaml is a pretty damn fast language. It's incremental build times dwarf that of almost any other language. Since Reason is just a toolchain on top of OCaml, it maintains the many of the same characteristics of OCaml.

For instance take a look at this table from the docs of fastpack, an alternative to Webpack or Parcel for bundling JavaScript applications.

~1100 modules / 5.3Mb / MB Pro 2017

	Fastpack	Webpack	Parcel
initial build	0.811s	3.86s	11.07s
persistent cache	0.208s	N/A	1.39s
watch mode	0.088s	0.226s	0.291s

Fastpack is still rather new but these numbers are promising -- and the result implies we can made super-quick devtools for a vanilla JavaScript workflow.

Static Typing

Another thing Reason inherits from OCaml is a power, nearly impenetrable type system. The compiler does a solid job of making sure you exhaust all of your options in branching logic.

It also does away with silly errors like "undefined is not a function" or "cannot read property 'x'". The same could be said about adopting TypeScript or Flow, but they do not force you to cover such cases.

...with Great Inference

It's powerful type inference cleans up a lot of the verbosity associated with annotating functions and variables with types. The following function adds two integers. Not two floats or two strings, just two integers.

  /* the type system knows that the arguments and the return value are ints here */
  let add = (a, b) => a + b;

If that example is too basic, then try this one. Note how I am not annotating the types in the function signatures:

  type animal =
    | Dog
    | Cat
    | Octopus;

  let animalToString = animal =>
    switch(animal) {
    | Dog => "dog"
    | Cat => "cat"
    | Octopus => "octopus"
    };

  let getWelcomeMessage = (name, visits, animal) => {
    "Hello " ++
    name ++
    ", you've visited this website " ++
    string_of_int(visits) ++
    " times and your favorite animal is the " ++
    animalToString(animal);
  };

The ReasonML/OCaml type system is capable of inferring based on our usage what the return types are, as well as each of the arguments. How neat is that?

Industry Proven

OCaml is a proven language of academics and industries where safety and mission critical code is paramount. This was one of the reason's it was adopted as the base for ReasonML.

At Facebook, OCaml is used to build some of their important everyday tools, like Flow and Hack. But they're also working on Reason, which in my opinion, is neat because Reason brings more joy than flow.

The Wit of JavaScript

With Reason comes a lighter, more JavaScript-like syntax. The first example I showed above would work just as well in regular JavaScript. One of the nice parts about writing vanilla JavaScript is that you can write pretty simply looking code that just works.

Add in TypeScript or Flow and you have less simple code with perhaps some awkward function signatures. Reason leverages OCaml's type inference to reduce the density of code in our programs considerably.

The result is a simple footprint like we'd read in a JavaScript program with all of the power of an OCaml script.

Syntax

Reason syntax is far easier to read and digest than that of OCaml, and most other functional languages for that matter. Let's take a look at this example from Cohttp, a library like Express or Axios for creating and handling HTTP requests.

This is a simple GET request with that library:

open Lwt
open Cohttp
open Cohttp_lwt_unix

let body =
  Client.get (Uri.of_string "https://ianwilson.io/") >>= fun (resp, body) ->
  let code = resp |> Response.status |> Code.code_of_status in
  Printf.printf "Response code: %d\n" code;
  Printf.printf "Headers: %s\n" (resp |> Response.headers |> Header.to_string);
  body |> Cohttp_lwt.Body.to_string >|= fun body ->
  Printf.printf "Body of length: %d\n" (String.length body);
  body

let () =
  let body = Lwt_main.run body in
  print_endline ("Received body \n" ^ body)

Now if your background doesn't contain OCaml you may just want to look away. There are some funky operators working in that example. For instance:

the first let binding is... a closure?
what the heck is >>= and >|=?
why does it use "->" instead of "=>"?
whats up with the selective use of parenthesis?
why is there so much piping?
whats up with the fun keyword?
what does the keyword in mean here?
what issue does OCaml have with curly braces?

Some of these questions are just syntactic funsies we learn to deal with in OCaml. The piping is common to many other functional programming languages, and it makes for a cleaner data pipeline in some cases.

What might this same example look like in Reason?

open Lwt;
open Cohttp;
open Cohttp_lwt_unix;

let body = 
  Client.get(Uri.of_string("https://ianwilson.io/")) >>= (resp, body) => {
    let code = resp |> Response.status |> Code.code_of_status;
    let headers = resp |> Response.headers |> Header.to_string;
    Printf.printf("Response code: %d\n", code);
    Printf.printf("Headers: %s\n", headers);
    body |> Cohttp_lwt.Body.to_string >|= (body) => {
      Printf.printf("Body of length: %d\n", (String.length(body));
      body;
    }
  }


let () = {
  let body = Lwt_main.run(body);
  print_endline("Received body \n" ++ body);
}

I think this code is a little easier to read. Those funky operators are still there but I'll note that they exist to help deal with OCaml promises, sometimes referred to as "lightweight threads".

Reason code takes the good parts of JavaScript style and OCaml style and finds a happy middle ground where people can be stylish and functional.

Easy Build System

Reason massively more accessible to newcomers than OCaml in that you probably wont spend days trying to install your dependencies properly. When using BuckleScript its often just another npm install {package}, then adding the name of that package to a bsconfig file.

The workflow for compiling to native is still a work in progress but Esy is working towards making it smooth.

If you need training wheels when writing Reason, do not fear. You can use special directives to write JavaScript directly in your Reason code. Its not cheating, the language was designed this way to make migrating codebases easier.

Reason's interoperability with JavaScript makes it a little more accessible until the developer is comfortable with removing the escape hatches. This is similar to using any in TypeScript.

The Courage of Reason

Over the past few weeks, I've been exploring writing Native Reason code. I think some of the projects that are being developed show great courage in showing off the potential of ReasonML.

While I certainly appreciate it's benefits on the frontend when transpiled to JavaScript, it would be super neat if I could write it on the server too.

I want to communicate with databases, make blazing quick command line tools, and write super efficient servers, perhaps serving GraphQL.

And I want to do it with the same language that I'm writing in for my web applications.

Currently, we can do this with JavaScript, but I think we can do better.

By further leveraging the OCaml ecosystem we can actually write incredibly robust servers and developer tools.

The Esy package manager allows us to install and build packages from npm or opam in a convenient package.json fashion without having to manually hack system dependencies.

As Esy further develops, Reason on the backend will become increasingly more accessible to developers looking to write stupidly fast native code.

If you're interested in what's already been made with Esy, check out the following projects:

fnm, an alternative to nvm for managing your NodeJS version. It's much faster than nvm.
fastpack, a ridiculously fast JavaScript bundler
revery, a desktop UI framework like electron, except without downloading a whole browser onto your users' computer.

And there are more out there in the Forests of Open Source.

This certainly won't be my last post on this topic so stay tuned for more Reason evangelism on the horizon.

If you want to how ReasonML works seamlessly with GraphQL, check out this article I wrote on ReasonML with GraphQL, the Future of Type-Safe Web Applications.

If you'd like to keep up with future posts, sign up for my newsletter here!

ReasonML with GraphQL, the Future of Type-Safe Web Applications

Ian Wilson — Wed, 13 Mar 2019 19:52:36 +0000

ReasonML, also known as JavaScript-flavored OCaml, offers nearly impenetrable type safety for developing user interfaces. By adopting a static type system, you can eliminate an entire class of errors before your app is served.

We’re going to look into building a small web application that uses consumes a GraphQL endpoint using ReasonML. We’ll cover:

getting started with a ReasonReact project
setting up a client with reason-apollo
sending queries
mutating data

If you’re new to both GraphQL and ReasonML, I’d suggest learning one at a time. Learning more than one big thing at once is often difficult for me. If you’re experienced with JavaScript and GraphQL, but want to learn ReasonML, read on, but keep the docs handy.

Getting Started - Establishing a ReasonReact Project

In order to get going with ReasonML, we must first install the cli, bsb-platform that handles bootstrapping the project. You should also get an editor plugin that helps with developing ReasonML apps. If you’re using VSCode, reason-vscode by Jared Forsyth is my preferred plugin.

npm install -g bsb-platform

This installs the BuckleScript compiler that turns our ReasonML into wonderful JavaScript which has already been type-checked and can be run in the browser.

Now we can initialize our project and hop right in.

bsb -init reason-graphql-example -theme react
cd reason-graphql-example
npm install

The init argument specifies the name of the project we’re initializing.
The theme argument specifies the template we wish to use. I usually just choose the react theme.
We run npm install to install dependences just like in any other JavaScript project.

With the project scaffolded, we can try to build it. In two separate terminal panes, run:

npm start
# and
npm run webpack

npm start tells BuckleScript (bsb) to build the project watch for changes to your .re files.
npm run webpack fires up webpack to build your main JavaScript bundle

Quick tip: you’ll notice that the webpack output is in the build folder but the index.html file is in the src folder. We can make serving the project a little bit easier by moving the index.html file to the build folder and rewriting the script tag to point at the adjacent Index.js file.

With all that taken care of, you can serve your build folder using http-server build or serve build and check out the project.

When I’m developing a ReasonML project, I’m running 3 terminal tabs:

npm start to transpile ReasonML to JavaScript
npm run webpack to bundle JavaScript
serve build to actually serve the build on a port

Before we can get to the fun stuff, we still must clear out the boilerplate and set up react-apollo.

Go ahead and remove the Component1 and Component2 files, and then update Index.re to the following:

ReactDOMRe.renderToElementWithId(<App />, "root");

Update index.html to:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>ReasonML GraphQL Example</title>
  </head>
  <body>
    <div id="root"></div>

    <script src="./Index.js"></script>
  </body>
</html>

Finally, create an App.re file and add the following:

/* App.re */
let str = ReasonReact.string;
let component = ReasonReact.statelessComponent("App");

let make = _children => {
  ...component,
  render: _self => 
    <div> 
      <h1> {"Hello ReasonReact" |> str} </h1>
    </div>
};

You might have to re-run your terminal commands, but with all that said and done, you should have something like this appear on your screen:

It feels like a lot of effort to get started, but accepting early friction for a smoother experience later on is the tradeoff here.

Initializing Reason Apollo

In order to get set up with Apollo we’re going to run:

npm install -S reason-apollo react-apollo apollo-client apollo-cache-inmemory apollo-link apollo-link-context apollo-link-error apollo-link-http graphql graphql-tag apollo-link-ws apollo-upload-client subscriptions-transport-ws

That looks like a big install command. It is, but only the first package, reason-apollo, is consumed in our ReasonML code. However, reason-apollo is a library of binding labels depends on these other JavaScript packages.

In order to make writing GraphQL queries more friendly we’ll need one more dev dependency.

npm install -D graphql_ppx

As that installs we can open up our bsconfig.json file and update the “bs-dependencies” and “ppx-flags” keys like so:

// bsconfig.json
{
    "bs-dependencies": [
        "reason-react",
        "reason-apollo"
    ],
    "ppx-flags": [
        "graphql_ppx/ppx"
    ],

    // other fields...
}

The “bs-dependencies” array tells BuckleScript to include those npm modules in the build process. The ppx flags array lets our IDE know how to handle preprocess certain directives, GraphQL in our case.

Create a file inside the src folder called Client.re. This is where we will declare our instance of the Apollo Client.

/* Client.re */
let inMemoryCache = ApolloInMemoryCache.createInMemoryCache();

let httpLink =
  ApolloLinks.createHttpLink(~uri="https://video-game-api-pvibqsoxza.now.sh/graphql", ());

let instance =
  ReasonApollo.createApolloClient(~link=httpLink, ~cache=inMemoryCache, ());

Note: If this uri, https://video-game-api-pvibqsoxza.now.sh/graphql does not work, please send me a message on twitter or here in the comments and I’ll update that as quickly as possible

When we work with ReasonML, any variable that we create with a let binding is automatically exported from the module for us.

With the instance created, we can reference it in any of our other .re files. Update Index.re to the following:

/* Index.re */
ReactDOMRe.renderToElementWithId(
  <ReasonApollo.Provider client=Client.instance>
    <App />
  </ReasonApollo.Provider>,
  "root",
);

It looks a little like a standard React JS application, with a couple caveats. Notice that there are no import statements. In ReasonML, we have access to all of the namespaces built in our application. From the perspective of Index.re, We can see the Client and the App modules.

When we create a .re file in our src folder, it becomes a module. We could also declare our modules explicitly within our files.

It is now time to consume our API.

Sending Queries and Rendering a List

While writing this article I created a small Node GraphQL server, the code of which is available at this repo. To keep costs low, I declared an array of mock data to return on each GraphQL request rather than host a database.

Rather than create a todo app, I decided to create a list of video games that I played at some point long ago. Then, I could check if I finished it or not, thus remembering the games that I still haven’t beat.

As we are working with a GraphQL server, we should be able to figure out exactly how to call it by observing the schema.

  type VideoGame {
    id: ID!
    title: String!
    developer: String!
    completed: Boolean!
  }

  type Query {
    videoGames: [VideoGame!]!
  }

  type Mutation {
    completeGame(id: ID!): VideoGame!
  }

Currently, we have one query and one mutation, both of which operate around this VideoGame type. A GraphQL adept will notice that every return value is non-nullable, that is, these responses cannot return unset fields or null objects.

Soon we’ll see why all of the !’s are particularly important for our ReasonML code.

Let’s begin by defining the query in on top of App.re, just below the component declaration.

/* App.re */ 

module VideoGames = [%graphql
  {|
  query VideoGames {
    videoGames {
      id
      title
      developer
      completed
    }
  }
|}
];

module VideoGamesQuery = ReasonApollo.CreateQuery(VideoGames);

/* let make = ... */

Comparing with the JavaScript in react-apollo, this code would be most analogous to:

const VideoGames = gql`
  query VideoGames {
    videoGames {
      id
      title
      developer
      completed
    }
  }
`

// later in render
render() {
  return (
    <Query query={VideoGames}> {/* ... */} </Query>
  )
}

Now let’s update the render function:

/* App.re */
let make = _children => {
  ...component,
  render: _self => {
    let videoGamesQuery = VideoGames.make();
    <div> 
        <h1> {"ReasonML + ReasonReact + GraphQL" |> str} </h1>
        <VideoGamesQuery variables=videoGamesQuery##variables>
        ...{
             ({result}) =>
               switch (result) {
               | Loading => <div> {"Loading video games!" |> str} </div>
               | Error(error) => <div> {error##message |> str} </div>
               | Data(data) => <VideoGameList items=data##videoGames />
               }
           }
      </VideoGamesQuery>
    </div>;
  }
};

Here, we’re taking advantage of ReasonML’s coolest feature - pattern matching. Pattern matching combined with variants makes the logic that you would otherwise put in branches of if-else statements more linear and easier to follow. It is also reduces branch checking to constant rather than linear time, making it more efficient.

If the ReasonML code ever seems more verbose, just remember we’re still getting perfect type safety when it compiles. We still need to build the VideoGamesList component as well as define the videoGame record type.

Starting with the record type, create a new file called VideoGame.re and add the following:

/* VideoGame.re */

[@bs.deriving jsConverter]
type videoGame = {
  id: string,
  title: string,
  developer: string,
  completed: bool,
};

The videoGame type as we have it here, has 4 fields, none of which are optional. The BuckleScript directive above it adds a pair of exported utility methods that allow us to convert between ReasonML records and JavaScript objects.

Tip: when Apollo returns a response, it returns untyped JavaScript objects. The jsConverter directive gives us an exported method called videoGameFromJs that we can use to map the Apollo query data to fully typed ReasonML.

To see this mechanic in action, create a new file called VideoGameList.re and add:

/* VideoGameList.re */
open VideoGame;

let str = ReasonReact.string;
let component = ReasonReact.statelessComponent("VideoGameList");

let make = (~items, _children) => {
  ...component,
  render: _self =>
    <ul style={ReactDOMRe.Style.make(~listStyleType="none", ())}>
      {
        items
        |> Array.map(videoGameFromJs)
        |> Array.map(item =>
             <li key={item.id}>
                <input
                  id={item.id}
                  type_="checkbox"
                  checked={item.completed}
                />
                <label htmlFor={item.id}>
                  {item.title ++ " | " ++ item.developer |> str}
                </label>
             </li>
           )
        |> ReasonReact.array
      }
    </ul>,
};

Open the VideoGame module (VideoGame.re) at the top so we can use all of it’s exports in the VideoGameList module.
Declare the component type and string rendering shorthand.
Define a make function that expects one prop, items.
Inside the render function, pipe the items to convert JS objects to ReasonML records, map records to JSX, and finally output them as an array.

Note: Piping basically reverses the order of function calls to potentially improve readability. With the |> operator, the items object is applied to each function as the last argument.

Though I like prefer the piping style, the following are equivalent.

items 
    |> Array.map(videoGameFromJs)
    |> Array.map(renderItem)
    |> ReasonReact.array;

ReasonReact.array(
    Array.map(
        renderItem,
        Array.map(
            videoGameFromJs,
            items
        )
    )
);

I think we are ready to once again compile and serve our project. If you haven’t already, run this command in your project root:

yarn send-introspection-query https://video-game-api-pvibqsoxza.now.sh/graphql

This generates a graphql_schema.json file that Reason Apollo uses to type check your queries. If your ReasonML app asks for a field that isn’t on the schema, or if it doesn’t properly handle optional data types, it will not compile.

The strict typing serves as a wonderful sanity check for writing queries and mutations.

When all is said and done, you should see the following.

Don’t yell at me for not finishing the main story in Skyrim.

Mutating Data

One thing you may notice thus far is that clicking the checkboxes doesn’t do anything. This is expected, since we have not yet wired up a mutation.

Let us begin by recalling our schema above, and creating a module for the mutation to mark a game completed.

Inside VideoGameList.re, add these modules to the top of the file just beneath the call to create a component.

/* VideoGameList.re */
module CompleteGame = [%graphql
  {|
  mutation CompleteGame($id: ID!) {
    completeGame(id: $id) {
      id
      completed
    }
  }
|}
];

module CompleteGameMutation = ReasonApollo.CreateMutation(CompleteGame);

For the render prop of the mutation, it’ll look pretty similar to the JavaScript version. I’ll put this code here and then walk through it, starting from inside the <li> tag.

/* VideoGameList.re */

<li key={item.id}>
  <CompleteGameMutation>
    ...{
        (mutate, {result}) => {
          let loading = result == Loading;
          <div>
            <input
              id={item.id}
              type_="checkbox"
              checked={item.completed}
              onChange={
                _event => {
                  let completeGame =
                    CompleteGame.make(~id=item.id, ());
                  mutate(~variables=completeGame##variables, ())
                  |> ignore;
                }
              }
            />
            <label
              htmlFor={item.id}
              style={
                ReactDOMRe.Style.make(
                  ~color=loading ? "orange" : "default",
                  (),
                )
              }>
              {item.title ++ " | " ++ item.developer |> str}
            </label>
          </div>;
        }
      }
  </CompleteGameMutation>
</li>

Like the Apollo VideoGamesQuery component we used earlier, the CompleteGameMutation component we see here passes to its children a mutate function as well as a results object.

This particular component is not the best example to show off how you could use that results object, as I only take advantage of it when a single item is being updated. If it is, I color the text of the item label green and call that the loading state.

I’m no UX guy, but I think that’ll do for today.

Wrapping Up

ReasonML is a pretty powerful and expressive language. If you are new to ReasonML and itching to build some type safe user interfaces, here are some resources to learn from:

Many of the third party tools we use in JavaScript come out of the box with ReasonML. This article by David Kopal explains how, along with some other reasons why writing ReasonML is so cool.
Jared Forsyth’s blog has great content about ReasonML and OCaml. He is one of the most active contributors to the community.
I get most of my learning done through the ReasonML docs and the BuckleScript docs. They are easy to follow and contain powerful insights on the design choices when implementing language features.

If you want to quickly set up your own GraphQL server then check out my other article, Learn to Build a GraphQL Server with Minimal Effort.

I hope to write more articles about ReasonML and GraphQL in the future. If these interest you then by all means follow me on Medium and on Twitter!

This article was originally published in Open GraphQL on Medium.

Intro to ReasonML Variants

Ian Wilson — Thu, 07 Mar 2019 08:20:37 +0000

ReasonML is a super fast, expressive, and functional programming language. Currently, it can be compiled to optimized JavaScript for the web, WebGL/OpenGL for native graphics rendering, or even native bytecode.

One of my favorite features of Reason are variant data types. These types allow us to handle enums in a sane way, forcing us to handle all possibilities for a particular scenario. We can define a variant type like this:

type color =
  | Red
  | Blue
  | White
  | Black
  | Grey;

We see that the type color can be represented as this enumeration of different colors. Not too complicated, but not too enlightening either. In JavaScript, we could handle this with an object mapping:

const COLORS = {
  RED: 'red',
  BLUE: 'blue',
  WHITE: 'white',
  BLACK: 'black',
  GREY: 'grey',
}

I use maps like this all the time in my JavaScript projects, they help a ton when your goal is to keep constants defined in the same place. If you need to update, add, or remove a field, you only need to do so in one location.

If this were the whole story, I would probably decide that a compiled-to-js programming language like Reason is not worth the effort involved when I could just add TypeScript support. After all, it has only saved us a tiny amount of code.

Let's take a look at an example to see how Reason would help us where ordinary JavaScript falls short.

function getMonthlyPriceForCarColor(color) {
  switch(color) {
    case COLORS.RED:
      return 28;
    case COLORS.BLUE:
      return 24;
    case COLORS.WHITE:
      return 20;
  }
}

This function takes a color (from our convenient colors lookup-map) and returns to us the additional monthly price of getting a Tesla Model S. In other words, getting a red Tesla costs more because it is the best color.

One other thing you might notice is that I did not provide a default case, and as an imperfect programmer, I neglected some of the other colors. JavaScript will not yell at me for this on its own, so I will probably have to find out the hard way that I forgot some of the other cases.

Hopefully QA will catch this bug before my code lands in production. But even if they're really thorough, I'd still have to make changes and push/review more code. Wouldn't it be nice if our typechecker could alert us on the fly?

The same function in Reason looks like this:

let getMonthlyPriceForCarColor = color =>
  switch(color) {
    | Red => 28
    | Blue => 24
    | White => 20
  };

First of all there's less code, which is great, but beside the point. In practice, this function will actually have red squiggly underlines, alerting us that our switch is not exhaustive - it does not cover all of the possibilities or our color variant.

The error message is actually quite helpful when this happens.

Fixing this issue simply requires that you cover the other possibilities.

let getMonthlyPriceForCarColor = color =>
  switch(color) {
    | Red => 28
    | Blue => 24
    | White => 20
    | Black => 0
    | Grey => 0
  };

Reason wont let us compile our code if we don't have a case for each possibility in this function. This is a sampling of the incredibly powerful type system we have with Reason.

Variants as Constructors

As I've demonstrated so far, variants can be used as enumerations, but they exhibit a power that takes enumeration to a whole new level. Variants can be used as generic constructors that take arguments, allowing developers to further customize applications for their use case.

For example, we can adjust our price based on the shade of grey or even go as far as to specify a totally arbitrary color somewhere in the RGB scale.

Updating our color type to the following:

type color =
  | Red
  | Blue
  | White
  | Black
  | Grey(float)
  | Rgb(int, int, int);

Now when we run our function, we can let the customer to pick whatever color they want. To keep make the pricing more reasonable with our already hardcoded values, we'll allow grey to range from $0 to $20. depending on whatever number given between 0.0 and 1.0.

The Rgb constructor will be the most expensive since we have to create new paint in order to satisfy that requirement. The higher the values of red, blue, and green color, the closer to $36 it will be.

let getMonthlyPriceForCarColor = color =>
  switch(color) {
    | Red => 28
    | Blue => 24
    | White => 20
    | Black => 0
    | Grey(pct) => int_of_float(pct *. 20.0)
    | Rgb(red, green, blue) => {
      /* completely random calculation. Tesla probably does not do this */
      let sum = red + green + blue;
      if (sum > 500) {
        36
      } else {
        32
      }
    }
  };

Js.log(getMonthlyPriceForCarColor(Red));                /* 28 */
Js.log(getMonthlyPriceForCarColor(Grey(0.64)));         /* 12 */
Js.log(getMonthlyPriceForCarColor(Rgb(150, 210, 67)));  /* 32 */
Js.log(getMonthlyPriceForCarColor(Rgb(150, 210, 167))); /* 36 */

This is pretty neat huh? This example displays the expressive power of a robust type-safe language like Reason.

The only thing I have yet to do to make this example stronger, is validate the constructor inputs. So to send off this post with a bang, I am going to make some helper functions.

let validatePercentage = pct =>
  restrictRangef(pct, 0.0, 1.0);

let validateRgb = (red, blue, green) => {
  let red = restrictRange(red, 0, 255);
  let green = restrictRange(green, 0, 255);
  let blue = restrictRange(blue, 0, 255);
  (red, blue, green);
};

These functions validate the required input to the extend that they cut off the values if they are too low or too high. Here are their corresponding restrictRange functions.

let restrictRange = (number, min, max) => 
  if (number > max) {
    max;
  } else if (number < min) {
    min;
  } else {
    number;
  };

let restrictRangef = (number, min, max) => 
  if (number > max) {
    max;
  } else if (number < min) {
    min;
  } else {
    number;
  };

One last thing to note is that we must have separate restrictRange functions for int and float types. By convention, when we have functions that take ints, their float variation will have the same name but with an "f" at the end.

A little extra code here is a small price to pay here when we have superior type coverage.

Finally I can update our getMonthlyPriceForCarColor function with our new helpers:

let getMonthlyPriceForCarColor = color =>
  switch (color) {
  | Red => 28
  | Blue => 24
  | White => 20
  | Black => 0
  | Grey(pct) => int_of_float(validatePercentage(pct) *. 20.0)
  | Rgb(red, green, blue) => {
      let (r, g, b) = validateRgb(red, green, blue);
      let sum = r + g + b;
      if (sum > 500) {
        36
      } else {
        32
      };
    }
  };

And thats a wrap

If you'd like to take a look at the example file I wrote to make sure I was giving you type-safe code, you may view it on GitHub here.

We've taken a look at variants and how we can use them with constructor arguments through pattern matching. This is a super powerful feature that you won't find in just any modern programming language.

When you build an application with complete type safety, you begin to reap the advantages as the size of your project grows and you begin to make refactors. Knowing that your code compiles increases your confidence that you wont break critical or even basic features in production.

If you'd like to keep up with future posts, sign up for my newsletter here!

How a Type System Improves your JavaScript Code

Ian Wilson — Sun, 24 Feb 2019 19:24:06 +0000

Vanilla JavaScript is untyped by nature, some will call it “smart” because it is able to figure out what is a number or a string.

This makes it easier to run JavaScript code, it simply needs to be executed in a browser or Node.js runtime. However, its vulnerable to numerous runtime errors that can spoil your user experience.

If you’ve ever experienced the following, you would benefit from adopting a type system.

After fetching a list of data you may find that a certain field doesn’t exist on one of the records, causing the app to crash unless explicitly handled.
An instance of a class you imported doesn’t have a method you’re trying to invoke.
Your IDE doesn’t know what methods and properties are available, so it cannot easily assist you with autocomplete.
Difficulty reasoning about code, type systems at a glance make it easier to refactor

Flow, TypeScript, or ReasonML

Let's say you have an existing codebase that you wish to make bulletproof. With respect to type errors, you could try adopting Flow or TypeScript -- they have a fairly similar syntax.

On the other hand adopting one of these in a large, existing codebase is difficult. You would have a backlog crammed with tasks relating to creating types and interfaces with code that made not have been designed in a type friendly way.

On top of all of this, Flow and TypeScript do not offer 100% type safety in their code.

Reason accomplished perfect type safety through inference, and makes annotating variables and function signatures much more straightforward.

Simple and Clearly Contrived Examples

Consider the following code:

let add = (a, b) => a + b;

In basic JavaScript these arguments can be numbers or strings. In TypeScript or Flow these arguments can be annotated like so

let add = (a: number, b: number) => a + b

The first code snippet knows that we are adding two int values. Not two floats nor two strings, there are different operators for those addition operations. JavaScript can hardly tell the difference between an int and a float.

Allow me now to expose this gradual typing with a contrived example.

let add = (a: string, b: number) => a + b
add('some string', 5) // outputs: "some string5"

That function works! This is absolutely preposterous! Now how does Reason handle this?

let add = (a, b) => a + b;
add("some string", 5);
/*
This has type:
  string
but somewhere wanted:
  int
*/

This function was flawed at the implementation level. Reason has different operators for int, float, and string addition.

The purpose of this contrived example was to show that it is still very possible to have odd type "errors" even though it wont break the application.

In a pure Reason program, developers will not have to deal with productions bugs that have to do with types or null values.

Developer Experience

One of the neatest features of TypeScript is the enhancement you get in code editor suggestions & autocompletion.

This is one area where TypeScript has a leg up on Reason, because a TypeScript program doesn't need to compile perfectly in order to offer autocompletion. Reason makes you fix errors in syntax or types before it gives you helpful autosuggestion.

This is the case on VSCode, but I know many Reason developers use vim. I cannot answer for the level of support each editor has.

Even though I am a big fan of ReasonML, I have built production applications with TypeScript or Flow and I enjoy them as well. The wave behind TypeScript makes it especially good to pick up these days, considering there is plenty of writing and community support behind it.

Reason on the other hand is harder to pick up because there is comparatively less writing and content behind it. Through blog posts like this, I am hoping to change that.

If you have some interest in checking out Reason, I'd start with the docs here. Also, be sure to follow people like @jordwalke, @jaredforsyth, and @sgrove on twitter. They are pretty knowledgable with respect to the ReasonML/OCaml ecosystem.

If you want to how ReasonML works seamlessly with GraphQL, check out this article I wrote on ReasonML with GraphQL, the Future of Type-Safe Web Applications.

If you'd like to keep up with future posts, sign up for my newsletter here!

How Apollo Saves Us Effort in Jump Starting a GraphQL Server

Ian Wilson — Wed, 01 Aug 2018 20:17:11 +0000

How Apollo Saves Us Effort in Jump Starting a GraphQL Server

A couple years ago I spun up my first Node HTTP server with Express. It took only 5 lines of code on my end.

const express = require('express')
const app = express()

app.get('/', function(req, res) {
    res.send({ hello: 'there' })
})

app.listen(3000, () => 'Listening at http://localhost:3000')

This reduced the necessary effort for building server side apps greatly, especially considering we could use our familiar JavaScript!

I must say, a year or two ago, setting up a GraphQL server wasn’t this easy. There was a decision to be made in choosing to build it with Facebook’s Relay or Apollo. Both frameworks have their own opinions about how a GraphQL server should be built and consumed.

In the beginning, starting off with Apollo was a little simpler than Relay, but it still demanded a lot of configuration. There were many GraphQL internals that needed to be exported and used in order to write fairly basic queries.

Now its different — The Apollo ecosystem has developed tremendously since a couple years ago. Setting up a server has become so mind-bogglingly simple, we can do it in almost as few lines as the above example:

import express from 'express'
import { ApolloServer } from 'apollo-server-express'
import { resolvers, typeDefs } from './schema'

const PORT = process.env.PORT || 3500
const app = express()

const server = new ApolloServer({
  typeDefs,
  resolvers,
  playground: true
})

server.applyMiddleware({ app })

app.listen(PORT, () =>
  console.log(`Listening at http://localhost:${PORT}/graphql`)
)

We just define our type definitions and resolver functions in our schema and we are ready to roll. This would be similar to setting up route handlers for every operation we wanted to support, like GET /users/:id or POST /articles.

Here is an example of some type definitions:

export const typeDefs = gql`
  type User {
    id: ID
    name: String
    age: Int
    email: String
    friends: [User]
  }

  type Query {
    users: [User]
  }

  input CreateUserInput {
    id: Int
    name: String
    age: Int
    email: String
    friends: [Int]
  }

  type Mutation {
    createUser(input: CreateUserInput!): User
    updateUser(id: Int!, input: CreateUserInput!): User
    deleteUser(id: Int!): User
  }
`

So rather than define CRUD endpoints to gather and manipulate our users, we just declare the shape of the data and the relations between them.

In order to receive a query or mutation and make calls to the database, we define the resolvers with access to a data model like so:

export const resolvers = {
  Query: {
    users(source, args, context) {
      return userModel.list()
    }
  },
  User: {
    friends(source, args, context) {
      if (!source.friends || !source.friends.length) {
        return
      }

      return Promise.all(source.friends.map(({ id }) => userModel.find(id)))
    }
  },
  Mutation: {
    createUser(source, args, context) {
      return userModel.create(args.input)
    },
    updateUser(source, args, context) {
      return userModel.update(args.id, args.input)
    },
    deleteUser(source, args, context) {
      return userModel.delete(args.id)
    }
  }
}

The model handles the database queries or third-party api calls. This way we can keep the resolvers agnostic to where the data is coming from.

Apollo Server, Internally

Even a few months ago, there were more packages to deal with and more configuration to grok before you could truly do anything.

Defining resolvers took much more effort with setting up internal GraphQL types.

Defining and patching together the schema also took more creativity on the developers side. Apollo basically looked at all of this configuration “busywork” and abstracted it into a package that is easier to get started with— without sacrificing the configuration that you might still want.

Here, we have simply initialized a server instance and applied our express server as a middleware.

server.applyMiddleware({ app })

What happens when we pass our Express instance to Apollo Server?

Usually, when we set up an Express server we need to install

body-parser to read JSON payloads
CORS to deal with cross origin resource sharing
multer or some other multipart middleware to read file uploads

It winds up being a bunch of app.use(someMiddleware) commands inside our server. Apollo Server comes with all of that by default, which is why we hardly need to write any extra code or install more dependencies.

Coming Soon

I wrote another post that deals with setting up a GraphQL server with Apollo. Hopefully it’ll drop soon, but the example repo [is here] in case you’d like to check out the source code that will accompany it.

Working with Apollo and GraphQL has certainly improved my dev experience and made me more productive, hopefully you will find it the same!

If you enjoyed this article and would like to see more in the future, let me know in the comments and give me a follow on Twitter and Medium!

Build Real-time Apps by Learning WebSockets

Ian Wilson — Tue, 22 May 2018 07:06:59 +0000

As a studying web developer, once you learn to query external APIs to display data in your UI, a whole new world opens up.

When interviewing for UI developer positions at various companies, I would say something like, "just give me the endpoints and I'll handle the rest ;)".

All of their other questions like "How do you handle adversity?" or "How do you handle disputes with stakeholders?" become moot.

With HTTP requests, I can get data, I can post data, and I can delete data. I do it all - I am definitely a fit for your team whether you know it or not.

This sounds great in the echo chamber of my mind. I distinctly remember feeling like a champion developer because I knew how to send requests to REST APIs.

Then, they had me make a chat application.

The Issue with Polling

If you're like me, you didn't understand how chat apps worked when you became a web developer. You might've thought, hey I'll just send a GET request every half-second or so to retrieve the recent chat messages.

In JavaScript, that might look a little something like this:

let clearIntervalId
let messages = []

function pollChatMessages() {
  const clearIntervalId = setInterval(() => {
    messages = await axios.get('https://api.example.com/threads/1/messages') // totally fake url
  }, 500)
}

This is called polling, and it'll work for a little while. One of my clients couldn't tell the difference, so long as there were only a couple users.

This function would be executed on some interval inside a singleton that exists inside the scope of our web application. If we wanted to kill the polling we could call clearInterval(clearIntervalId).

If we were chatting with 10 people, we would be running 10 polls from our browser. Likewise, those 10 people would also be running a poll for each person they were chatting with.

And what if some threads have hundreds of messages? That is a ton of needlessly large requests for a simple chat app.

The problem here is that the use of polling assumes that there is no way for a client like our browser to subscribe to a server. We can do better with a little networking.

Networking Basics

Let's start with some networking basics, what is a socket?

A TCP socket is an endpoint instance defined by the combination of an IP address with a port, in the context of either a listening state (a server) or a particular TCP connection (a client, like your browser).

A TCP connection is defined by the pairing of two sockets.

There are three main kinds of transports that we commonly use in browser web applications:

XMLHTTPRequests, or just HTTP for short. Send a single request and get a single response. These are pretty common.
Server-Sent Events, or SSE. Send a long-lived request and be able to stream data from the server. Great for real-time data streaming, particularly when the client doesn't need to send messages back to the server.
WebSockets, the only transport that allows for bidirectional streaming of text and binary data. We'll dive a little further into it.

Here's a diagram I stole from High-Performance Browser Networking, which illustrates the communication flow between each of these transports. It's a good book to check out if you're serious about improving the performance of your web apps.

In most tutorials that deal with external data, you'll deal with the left-most paradigm's HTTP requests. Actually, all of these flows are initiated with an HTTP request, as shown by the blue arrows.

I don't commonly see articles or tutorials on SSE, but MDN has a good reference in case a one-way data stream sounds intriguing.

The third flow is most interesting to us - it gives us the ability to communicate with the server over a single long-lived connection.

Enter WebSockets

As described by the Mozilla Developer Docs,

WebSockets are an advanced technology that makes it possible to open an interactive communication session between the user's browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.

That's fantastic, we don't need to do any polling! But how does it work?

The lifecycle of a WebSocket connection between a client and server goes like this. Imagine our server is hosted at https://api.example.com on port 8080 and our client is someone's browser.

The client sends a GET request to api.example.com:8080, with a couple of headers that indicate it wants to establish a WebSocket connection with the server. One of these is called Sec-WebSocket-Key, and is used to secure the connection between the client and server. The server derives a response header from this key called Sec-WebSocket-Accept, which indicates that the server does indeed support WebSockets and that it doesn't try to process the request as an ordinary HTTP request.
The server responds with code 101 - Switching Protocols, indicating that the handshake is complete and the client/server can start exchanging messages encrypted over XOR. Sparing the details of this data masking, we can now publish and subscribe to text or binary messages over this connection.
At any point after a successful handshake either the client or server can send a ping in order to check whether the other party is still connected. If the recipient of the ping does not send back a pong, it may have been disconnected.

In JavaScript, we can connect to a WebSocket server like this:

const thread = document.getElementById('chat-thread-1')

const conn = new WebSocket('ws://api.example.com/threads/1')

conn.onclose = function(event) {
  console.log('Connection closed')
}

conn.onmessage = function(event) {
  console.log('Message received.')
  const message = document.createElement('p')
  message.textContent = event.data
  thread.append(message)
}

We can invoke the built-in WebSocket constructor to create a connection, at which point we can set up the event handlers to decides what happens when a message is received.

We can also send messages, what if we had an input element that the client could enter text to chat with other users? That sure would be useful.

function sendMessage() {
  const input = document.getElementById('chat-thread-1-input')
  conn.send(input.value)
  input.value = ''
}

Better yet, what if we wanted to communicate more complex data with a message type and a timestamp, perhaps in the form of JSON?

function sendMessage() {
  const input = document.getElementById('chat-thread-1-input')

  const message = {
    type: 'message',
    text: input.value,
    date: Date.now(),
  }

  conn.send(JSON.stringify(message))
  input.value = ''
}

With a little DOM manipulation, we are not far from a somewhat real-world chat application. Chats are neat and all, but what else can we do with this technology?

Other Applications of WebSockets

For this chat example, the application of WebSockets is obvious: send and receive text messages.

If you frequent dev.to then you might've noticed that they have a contest going on, called Build a Realtime App with Pusher.

The Pusher API is built on the basis of WebSockets. Some of its use cases include:

updating location in real-time, say for journies and deliveries
real-time graphs
collaboration over a browser, mobile, or IoT
online gaming

Personally, I'm thinking of building a cloud markdown editor that'll help me with editing and sharing posts in a single place. I'd store my markdown content on a server and ideally be able to view/edit it from my Mac or my phone.

If I want to share a post with someone to edit, I'd drop them a link and I'd be able to see their cursor and notes in real-time, similar to how a Google doc works.

Of course, part of the fun for me is implementing the server myself. Whether I'd consume a service like Pusher will depend on my productivity/pain with the implementation.

If this intrigues you as well, you may find these links useful:

Curious for more posts or witty remarks? Follow me on Medium, Github and Twitter!

How to build sturdy React Apps with TDD using Jest the React Testing Library

Ian Wilson — Sun, 20 May 2018 23:22:26 +0000

Build React Apps with TDD and the React Testing Library

“A couple of pineapples side by side on the beach.” by Pineapple Supply Co. on Unsplash

One thing I struggled with when I started learning React was testing my web apps in a way that is both useful and intuitive. I basically used Enzyme with Jest to shallow render a component every time I wanted to test it, absolutely abusing the snapshot feature.

Well, at least I actually wrote a test right?

You might have heard somewhere that writing unit and integration tests will improve the quality of the software you write. Having bad tests, on the other hand, breeds false confidence.

Recently, I attended a workshop with @kentcdodds where he taught us how to properly write integration tests for React applications. He also tricked us into using his new testing library, in favor of its emphasis on testing the application in the same way that a user would encounter it.

In this post, we will create build a comment feed built with React.

Getting Started

We're going to start off by running create-react-app and installing the dependencies. My assumption is that if you're astute enough to read an article about testing applications, you're probably already a familiar with installing and starting up javascript projects. I'll be using yarn rather than npm here.

create-react-app comment-feed
cd comment-feed
yarn

As it stands, we can remove all of the files in the src directory except for index.js. Then, right inside the src folder, create a new folder called components and a folder called containers.

For testing utilities, I am going to build this app using Kent C Dodds' react-testing-library. It is a lightweight test utility that encourages the developer to test their application in the same way that it'll be used.

Like Enzyme, it exports a render function, but this render function always does a full mount of your component. It exports helper methods allowing you to locate elements by label or text or even test IDs. Enzyme does that as well with its mount API, but the abstraction it creates actually offers more options, many of which allow you to get away with testing implementation details.

We don't want to do that anymore. We want to render a component and see if the right things happen when we click or change something. That's it! No more directly checking props or state or class names.

Let's install them and get to work.

yarn add react-testing-library

Building the Comment Feed with TDD

Let's do this first component TDD-style. Fire up your test runner.

yarn test --watch

Inside the containers folder, we are going to add a file called CommentFeed.js. Alongside it, add a file called CommentFeed.test.js. For the very first test, let us verify that users can create comments. Too soon? Okay, since we don't have any code yet, we'll start with a smaller test. Let's check that we can render the feed.

// containers/CommentFeed.test.js
import { render } from 'react-testing-library'
import CommentFeed from './CommentFeed'

describe('CommentFeed', () => {
  it('renders the CommentFeed', () => {
    const { queryByText } = render(<CommentFeed />)
    const header = queryByText('Comment Feed')
    expect(header.innerHTML).toBe('Comment Feed')
  })
})

Some notes on react-testing-library

First, let us note the render function here. It is very similar to the way react-dom renders a component onto the DOM, but it returns an object which we can destructure to get some neat test helpers. In this case, we get queryByText, which, given some text we expect to see on the DOM, will return that HTML element.

The React Testing Library docs have a hierarchy that should help you decide which query or get method to use. Generally, the order goes like this:

getByLabelText (form inputs)
getByPlaceholderText (only if your input doesn't have a label - less accessible!)
getByText (buttons and headers)
getByAltText (images)
getByTestId (use this for things like dynamic text or otherwise odd elements you want to test)

Each of these has an associated queryByFoo that does the same, except won't fail your test when it doesn't find an element. Use these if you're just testing for the existence of an element.

If none of these get you exactly what you're looking for, the render method also returns the DOM element mapped to the container property, so you can use it like container.querySelector('body #root').

The First Implementation Code

Now, the implementation will look fairly simple, we just need to make sure that "Comment Feed" is in the component.

import React, { Component } from 'react'

export default class CommentFeed extends Component {
  render() {
    const { header } = this.props
    return (
      <div>
        <h2>{header}/h2>
      </div>
    )
  }
}

It could be worse, I mean, I was about to do this whole article with styling components too. Fortunately, tests don't care too much for styles so we can focus on our application logic. This next test will verify that we can render comments. But we don't even have any comments, so let's add in that component too.

After the test though. I'm also going to create a props object to store to data we may reuse in these tests.

// containers/CommentFeed.test.js
import { render } from 'react-testing-library'
import CommentFeed from './CommentFeed'

describe('CommentFeed', () => {
  const props = { header: 'Comment Feed', comments: [] }

  it('renders the CommentFeed', () => {
    const { queryByText } = render(<CommentFeed {...props} />)
    const header = queryByText(props.header)
    expect(header.innerHTML).toBe(props.header)
  })

  it('renders the comment list', () => {
    const { container } = render(<CommentFeed {...props} />)
    const commentNodes = container.querySelectorAll('.Comment')
    expect(commentNodes.length).toBe(props.comments.length)
  })
})

In this case, I am checking that the number of comments is equal to the number fed into the CommentFeed. It's trivial, but the failure of the test gives us the opportunity to create the Comment.js file.

import React from 'react'

const Comment = props => {
  return (
    <div className="Comment">
      <h4>{props.author}</h4>
      <p>{props.text}</p>
    </div>
  )
}

export default Comment

This green lights our test suite so can proceed without fear. All hail TDD, the savior of our kind. It works when we give it an empty array, of course. But what if we actually give it something?

describe('CommentFeed', () => {
  /* ... */

  it('renders the comment list with some entries', () => {
    let comments = [
      {
        author: 'Ian Wilson',
        text: 'A boats a boat but a mystery box could be anything.',
      },
      {
        author: 'Max Powers Jr',
        text: 'Krypton sucks.',
      },
    ]
    props = { header: 'Comment Feed', comments }
    const { container } = render(<CommentFeed {...props} />)
    const commentNodes = container.querySelectorAll('.Comment')
    expect(commentNodes.length).toBe(props.comments.length)
  })
})

We must update our implementation to actually render stuff now. Simple enough now that know where we're going, right?

import React, { Component } from 'react'
import Comment from '../components/Comment'

export default class CommentFeed extends Component {
  renderComments() {
    return this.props.comments.map((comment, i) => (
      <Comment key={i} {...comment} />
    ))
  }

  render() {
    const { header } = this.props
    return (
      <div className="CommentFeed">
        <h2>{header}</h2>
        <div className="comment-list">{this.renderComments()}</div>
      </div>
    )
  }
}

Ah look at that, our test is once again passing. Here's a neat shot of its beauty.

Notice how I never once said we should fire up our program with yarn start? We're going to keep it that way for a while. The point is, you must feel the code with your mind.

The styling is just what's on the outside; its what is on the inside that counts. ;)

Just in case you want to start the app though, update index.js to the following:

import React from 'react'
import ReactDOM from 'react-dom'
import CommentFeed from './containers/CommentFeed'

const comments = [
  {
    author: 'Ian Wilson',
    text: 'A boats a boat but a mystery box could be anything.',
  },
  {
    author: 'Max Powers Jr',
    text: 'Krypton sucks.',
  },
  {
    author: 'Kent Beck',
    text: 'Red, Green, Refactor.',
  },
]

ReactDOM.render(
  <CommentFeed comments={comments} />,
  document.getElementById('root')
)

The Add Comment Form

This is where things start getting more fun. This is where we go from sleepily checking for the existence of DOM nodes to actually doing stuff with that and validating behavior. All that other stuff was a warmup.

Let's start by describing what I want from this form. It should:

contain a text input for the author
contain a text input for then comment itself
have a submit button
eventually call the API or whatever service handles creating and storing the comment.

We can take down this list in a single integration test. For the previous test cases we took it rather slowly, but now we're going to pick up the pace and try to nail it in one fell swoop.

Notice how our test suite is developing? We went from hardcoding props inside their own test cases to creating a factory for them.

Arrange, Act, Assert

import React from 'react'
import { render, Simulate } from 'react-testing-library'
import CommentFeed from './CommentFeed'

// props factory to help us arrange tests for this component
const createProps = props => ({
  header: 'Comment Feed',
  comments: [
    {
      author: 'Ian Wilson',
      text: 'A boats a boat but a mystery box could be anything.',
    },
    {
      author: 'Max Powers Jr',
      text: 'Krypton sucks.',
    },
  ],
  createComment: jest.fn(),
  ...props,
})

describe('CommentFeed', () => {
  /* ... */

  it('allows the user to add a comment', () => {
    // Arrange - create props and locate elements
    const newComment = { author: 'Socrates', text: 'Why?' }
    let props = createProps()
    const { container, getByLabelText } = render(<CommentFeed {...props} />)

    const authorNode = getByLabelText('Author')
    const textNode = getByLabelText('Comment')
    const formNode = container.querySelector('form')

    // Act - simulate changes to elements
    authorNode.value = newComment.author
    textNode.value = newComment.text

    Simulate.change(authorNode)
    Simulate.change(textNode)

    Simulate.submit(formNode)

    // Assert - check whether the desired functions were called
    expect(props.createComment).toHaveBeenCalledTimes(1)
    expect(props.createComment).toHaveBeenCalledWith(newComment)
  })
})

This test can be broken into three parts: arrange, act, and assert. There are some assumptions made about the code, like the naming of our labels or the fact that we will have a createComment prop.

When finding inputs, we want to try to find them by their labels, this prioritizes accessibility when we're building our applications. The easiest way to grab the form is by using container.querySelector.

Next, we must assign new values to the inputs and simulate the change to update their state. This step may feel a little strange since normally we type one character at a time, updating the components state for each new character. This is more like the behavior of copy/paste, going from empty string to 'Socrates'.

After submitting the form, we can make assertions on things like which props were invoked and with what arguments. We could also use this moment to verify that the form inputs cleared.

Is it intimidating? No need to fear, my child, walk this way. Start by adding the form to your render function.

render() {
        const { header } = this.props
        return (
            <div className="CommentFeed">
                <h2>{header}</h2>

                <form
                    className="comment-form"
                    onSubmit={this.handleSubmit}
                >
                    <label htmlFor="author">
                        Author
                        <input
                            id="author"
                            type="text"
                            onChange={this.handleChange}
                        />
                    </label>
                    <label htmlFor="text">
                        Comment
                        <input
                            id="text"
                            type="text"
                            onChange={this.handleChange}
                        />
                    </label>

          <button type="submit">Submit Comment</button>
                </form>

                <div className="comment-list">
                    {this.renderComments()}
                </div>
            </div>
        )
    }

I could break this form into its own separate component, but I will refrain for now. Instead, I'll add it to my "Refactor Wish List" I keep beside my desk. This is the way of TDD. When something seems like it can be refactored, make a note of it and move on. Refactor only when the presence of an abstraction benefits you and doesn't feel unnecessary.

Remember when we refactored our test suite by creating the createProps factory? Just like that. We can refactor tests too.

Now, let's add in the handleChange and handleSubmit class methods. These get fired when we change an input or submit our form. I will also initialize our state.

export default class CommentFeed extends Component {
  state = {
    author: '',
    text: '',
  }

  handleSubmit = event => {
    event.preventDefault()
    const { author, text } = this.state
    this.props.createComment({ author, text })
  }

  handleChange = event => {
    this.setState({ [event.target.id]: event.target.value })
  }

  /* ... */
}

And that did it. Our tests are passing and we have something that sort of resembles a real application. How does our coverage look?

Not bad, if we ignore all of the setups that go inside index.js, we have a fully covered web application with respect to lines executed.

Of course, there are probably other cases we want to test in order to verify that the application is working as we intend. That coverage number is just something your boss can brag about when they're talking to the other cohorts.

Liking Comments

How about we check that we can like a comment? This may be a good time to establish some concept of authentication within our application. But we'll not jump too far just yet. Let us first update our props factory to add an auth field along with IDs for the comments we generate.

const createProps = props => ({
  auth: {
    name: 'Ian Wilson',
  },
  comments: [
    {
      id: 'comment-0',
      author: 'Ian Wilson',
      text: 'A boats a boat but a mystery box could be anything.',
    },
    {
      id: 'comment-1',
      author: 'Max Powers Jr',
      text: 'Krypton sucks.',
    },
  ],
  /*...*/
})

The user who is "authenticated" will have their auth property passed down through the application, any actions that are relevant to whether they are authenticated will be noted.

In many applications, this property may contain some sort of access token or cookie that is sent up when making requests to the server. On the client, the presence of this property lets the application know that they can let the user view their profile or other protected routes.

In this testing example, however, we will not fiddle too hard with authentication. Imagine a scenario like this: When you enter a chatroom, you give your screen name. From that point on, you are the in charge of every comment that uses this screen name, despite who else signed in with that name.

While it is not a great solution, even in this contrived example, we are only concerned with testing that the CommentFeed component behaves as it should. We are not concerned with how our users are logged in.

In other words, we may have a totally different login component that handles the authentication of a particular user, thus sending them through hoops of fire and fury in order to derive the almighty auth property that lets them wreak havoc in our application.

Let's "like" a comment. Add this next test case and then update the props factory to include likeComment.

const createProps = props => ({
  createComment: jest.fn(),
    likeComment: jest.fn(),
  ..props
})

describe('CommentFeed', () => {
  /* ... */

  it('allows the user to like a comment', () => {
    let props = createProps()
    let id = props.comments[1].id
    const { getByTestId } = render(<CommentFeed {...props} />)

    const likeNode = getByTestId(id)
    Simulate.click(likeNode)

    expect(props.likeComment).toHaveBeenCalledTimes(1)
    expect(props.likeComment).toHaveBeenCalledWith(id, props.auth.name)
  })
})

And now for the implementation, we'll start by updating the Comment component to have a like button as well as a data-testid attribute so we can locate it.

const Comment = props => {
  return (
    <div className="Comment">
      <h4>{props.author}</h4>
      <p>{props.text}</p>
      <button
        data-testid={props.id}
        onClick={() => props.onLike(props.id, props.author)}
      >
        Like
      </button>
    </div>
  )
}

I put the test id directly on the button so that we can immediately simulate a click on it without having to nest query selectors. I also attached an onClick handler to the button so that it calls the onLike function passed down to it.

Now we just add this class method to our CommentFeed:

handleLike = (id, author) => {
  this.props.likeComment(id, author)
}

You may wonder why we don't simply pass the likeComment prop directly to the Comment component, why do we make it a class property? In this case, because it is very simple, we don't have to build this abstraction. In the future, we may decide to add other onClick handlers that, for example, handle analytics events.

Being able to bundle multiple different function calls in the handleLike method of this container component has its advantages. We could also use this method to update the state of the component after a successful "Like" if we so choose.

Disliking Comments

At this point we have working tests for rendering, creating, and liking comments. Of course, we haven't implemented the logic that actually does that - we're not updating the store or writing to a database.

You might also notice that the logic we're testing is fragile and not terribly applicable to a real-world comment feed. For example, what if we tried to like a comment we already liked? Will it increment the likes count indefinitely, or will it unlike it?

I'll leave extending the functionality of the components to your imagination, but a good start would be to write a new test case. Here's one that builds off the assumption that we would like to implement disliking a comment we already liked:

const createProps = props => ({
  header: 'Comment Feed',
  comments: [
    {
      id: 'comment-0',
      author: 'Ian Wilson',
      text: 'A boats a boat but a mystery box could be anything.',
      likes: ['user-0'],
    },
    {
      id: 'comment-1',
      author: 'Max Powers Jr',
      text: 'Krypton sucks.',
      likes: [],
    },
  ],
  auth: {
    id: 'user-0',
    name: 'Ian Wilson',
  },
  createComment: jest.fn(),
  likeComment: jest.fn(),
  unlikeComment: jest.fn(),
  ...props,
})

describe('CommentFeed', () => {
  /* ... */

  it('allows the user to unlike a comment', () => {
    let props = createProps()
    let id = props.comments[0].id
    const { getByTestId } = render(<CommentFeed {...props} />)

    const likeNode = getByTestId(id)
    Simulate.click(likeNode)

    expect(props.unlikeComment).toHaveBeenCalledTimes(1)
    expect(props.unlikeComment).toHaveBeenCalledWith(id, props.auth)
  })
})

Notice that this comment feed we're building allows me to like my own comments. Who does that?

I have updated the Comment component with some logic to determine whether or not the current user has liked the comment.

const Comment = props => {
  const isLiked = props.likes.includes(props.currentUser.id)
  const onClick = isLiked
    ? () => props.onDislike(props.id)
    : () => props.onLike(props.id)
  return (
    <div className="Comment">
      <h4>{props.author}</h4>
      <p>{props.text}</p>

      <button data-testid={props.id} onClick={onClick}>
        {isLiked ? 'Unlike' : 'Like'}
      </button>
    </div>
  )
}

Well I cheated a little bit, where we were passing author to the onLike function before, I changed to currentUser, which is the auth prop passed down to the Comment component. I realized this because I was vigorously writing tests - had I just been coding by coincidence this might've slipped past me until one of my coworkers berated me for my ignorance!

But there is no ignorance here, just tests and the code that follows. Be sure to update the CommentFeed so that it expects to pass down the auth property. For the onClick handlers we can actually omit passing around the auth property, since we can derive that from the auth property in the parent's handleLike and handleDislike methods.

handleLike = id => {
        this.props.likeComment(id, this.props.auth)
    }

handleDislike = id => {
  this.props.dislikeComment(id, this.props.auth)
}

renderComments() {
  return this.props.comments.map((comment, i) => (
    <Comment
      key={i}
      {...comment}
      currentUser={this.props.auth}
      onDislike={this.handleDislike}
      onLike={this.handleLike}
    />
  ))
}

Wrapping up

Hopefully, your test suite is looking like an unlit Christmas tree.

There are so many different routes we can take at this, it can get a little overwhelming. Every time you get an idea for something, just write it down, either on paper or in a new test block.

For example, say you actually want to implement handleLike and handleDislike in one single class method, but you have other priorities right now. You can do this by documenting in a test case like so:

it('combines like and dislike methods', () => {})

This doesn't mean you need to write an entirely new test, you could also update the previous two cases. But the point is, you can use your test runner as a more imperative "To Do" list for your application.

Helpful Links

There are a few great pieces of content out there that deal with testing at large.

"Introducing the React Testing Library" by Kent C Dodds. It's a good idea to understand the philosophy behind this testing library.
"Software Testing Anti-patterns" by Kostis Kapelonis. An extremely in-depth article that discusses unit and integration testing. Also how not do to do them.
"Test Driven Development by Example" by Kent Beck. This is a physical book that discussed TDD patterns. It is not too long and it is written very conversationally, making it easy to digest.

I hope that'll tide you over for a while.

Curious for more posts or witty remarks? Follow me on Medium, Github and Twitter!

Originally published at medium.freecodecamp.org

DEV Community: Ian Wilson

The Evolution of the AI-Driven Coder

The stages of letting go

Agents unlock human agency

Mastering the File System with Rust

Overview of Key Functions

Reading files

Writing files

An Example: Copying files

Other Useful Methods

Thanks For Reading

Breaking Out of a Rut or Creative Block

Action Yields Action

Try Not to Go All-In

Smaller, Yet Effective Tips

Building Powerful GraphQL Servers with Rust

Setting up an HTTP Server

Creating the GraphQL Schema

Exposing the Schema

Setting up Postgres for Real Data

Wiring up our Handlers with Diesel

The Create Member Mutation

Thanks For Reading

Other Neat Reading Material

ReasonML with React Hooks Tutorial — Building a Pomodoro Timer

Initializing a Project

Running the code

Cleaning up the Environment

Building a Stateless Component

The useReducer Hook

The useEffect hook

Interactivity with Buttons

Aesthetic Concerns

Update the Document Title

Summary

ReasonML with GraphQL, the Future of Type-Safe Web Applications

Ian Wilson ・ Mar 13 '19

The Edge, Wit, and Courage of ReasonML

The Edge of OCaml

Speed

Static Typing

...with Great Inference

Industry Proven

The Wit of JavaScript

Syntax

Easy Build System

The Courage of Reason

ReasonML with GraphQL, the Future of Type-Safe Web Applications

Getting Started - Establishing a ReasonReact Project

Initializing Reason Apollo

Sending Queries and Rendering a List

Mutating Data

Wrapping Up

Intro to ReasonML Variants

Variants as Constructors

And thats a wrap

How a Type System Improves your JavaScript Code

Flow, TypeScript, or ReasonML

Simple and Clearly Contrived Examples

Developer Experience

How Apollo Saves Us Effort in Jump Starting a GraphQL Server

How Apollo Saves Us Effort in Jump Starting a GraphQL Server

Apollo Server, Internally

Coming Soon

Build Real-time Apps by Learning WebSockets

The Issue with Polling

Networking Basics

Enter WebSockets

Other Applications of WebSockets

How to build sturdy React Apps with TDD using Jest the React Testing Library

Build React Apps with TDD and the React Testing Library

Getting Started

Building the Comment Feed with TDD

Some notes on react-testing-library

The First Implementation Code

The Add Comment Form

Arrange, Act, Assert

Liking Comments

Disliking Comments

Wrapping up