Forem: Jeremy Ward 😎🤓

[WIP] Creating a Blackjack CLI game with Elixir

Jeremy Ward 😎🤓 — Sat, 20 Feb 2021 03:19:05 +0000

Day 6 of 100 Days of Code

Today I was able to work on my Blackjack CLI written in elixir. It's starting to shape up, but it still feels a little off. Here's a quick demo:

Update to the user experience

First I took advantage of elixir's pattern matching in functions to create a set of functions to calculate the value for a given card.

defmodule Card do
  ...
  def value(%{value: "J"}), do: 10
  def value(%{value: "Q"}), do: 10
  def value(%{value: "K"}), do: 10
  def value(%{value: "A"}), do: 11
  def value(%{value: value}), do: value
  ...
end

Next, I added a flash to displaying the cards by adding a white background and painting the card according to the suit.

defmodule Card do
  ...
  def display(%{suit: suit, value: value}) do
    IO.ANSI.color_background(15) <> IO.ANSI.color(color_code(suit)) <> "#{suit}#{value}" <> IO.ANSI.reset()
  end

  defp color_code("♥"), do: 9
  defp color_code("♦"), do: 9
  defp color_code("♣"), do: 0
  defp color_code("♠"), do: 0
end

Another bit of flare I added was chaning out the Deck @suits constant with the unicode icons for each suit. It's the little things you know?

Now, let's take a look at the changes to the Game module.

defmodule Game do
  # Added the "finished_players" attribute to the %Game struct. When a user
  # finishes their turn, they will be removed from the players list and placed
  # into the finished_players list.
  defstruct players: [%Player{name: "player_one"}, %Player{name: "dealer"}], cards: Deck.generate(), finished_players: []

  # After all users are removed from the players list, we can pattern match on
  # an empty players attr and finish the game.
  def play(%{players: []} = game) do
    game |> inspect_table()
  end

  # If there are still players, the play function logic will be a little
  # different, but with the pipe operator its pretty easy to follow.
  def play(game) do
    game
    |> deal()
    |> inspect_table()
    |> turn()
    |> play
  end

  # To handle a players turn, we just ask them if they want to Hit or Stay, and
  # build a new game struct accordingly.
  def turn(%{players: [current | players]} = game) do
    IO.puts "\n#{current.name} your move."
    case IO.gets("(H)it or (S)tay\n") |> String.downcase |> String.trim do
      "hit" -> deal_card(game, current)
      "h" -> deal_card(game, current)
      "stay" -> %{game | players: players, finished_players: [current | game.finished_players]}
      "s" -> %{game | players: players, finished_players: [current | game.finished_players]}
      _ -> game
    end
  end

  # Inspecting the table clears out the terminal, then displays info about for
  # the current state of the game
  defp inspect_table(%{players: players, finished_players: f_players} = game) do
    IO.write IO.ANSI.reset() <> IO.ANSI.clear() <> IO.ANSI.home()
    if length(players) == 0 do
      IO.puts "Game Over."
    end
    for player <- f_players ++ players do
      IO.puts "#{player.name}'s\n  hand: #{Player.display_hand(player)} |  #{player.total}"
    end
    game
  end
end

Implement the Dealer logic

In regular Blackjack, the deal has to hit if they have less than 17. I decided to replace %Player{name: "dealer"} with a %Dealer struct. With that in place I can use pattern matching again for the Game.turn/1 function which looks a little like this:

  def turn(%{players: [%Dealer{} = dealer | players]} = game) do
    cond do
      dealer.total >= 17 -> %{game | players: players, finished_players: [dealer | game.finished_players]}
      true -> deal_card(game, dealer)
    end
    |> inspect_table()
    |> (fn (game) ->
      IO.gets("Press enter to continue.")
      game
    end).()
  end

What's next?

If I want to finish Blackjack CLI, I would have to handle Aces. Aces can have a value of 1 or 11. This shouldn't be to hard, but might take some time. Other than that, It would be nice to choose how many decks could be played, and play to a certain percentage of the deck before regenerating the game.

I will prolly move on to the advance section of elixirschool.com, and come back to this repo later on.

Follow Me @

Twitter | Instagram

It's time for war. Code. War

Jeremy Ward 😎🤓 — Tue, 16 Feb 2021 02:21:25 +0000

Round 1. Day 4

Now equiped with the knowledge of elixir basics from ElixirSchool, I figure it is time I start practicing, and building my first elixir app. I started of today's practice with a code challenge from CodeWars. The Instructions were as follows:

Consider an array/list of sheep where some sheep may be missing from their place. We need a function that counts the number of sheep present in the array (true means present).
For example,

[true,  true,  true,  false,
  true,  true,  true,  true ,
  true,  false, true,  false,
  true,  false, false, true ,
  true,  true,  true,  true ,
  false, false, true,  true]

The correct answer would be 17.

The boilerplate code for this challenge was:

defmodule Shepherd do
  def count_sheeps(sheeps) do
    # TODO: for Elixir only true/false values can be presented the in sheeps list
  end
end

This challenge didn't seem too hard and it also felt a little familiar. I quickly went through my elixir school notes, and found a recursive counting function that would be a good template for solving this challenge. In the elixir school functions there was a function that counted the length of an array.

defmodule Length do
  def of([]), do: 0
  def of([_ | tail]), do: 1 + of(tail)
end

If we combine this logic with a little bit of pattern matching it should do the trick. And it did!

Spoiler Alert

WARNING: if you would like to try to solve the same codewar challenge, don't scroll any further.

Solution

defmodule Shepherd do
  # This form of the function was taken directly from the example at elixir
  # school.
  def count_sheeps([]), do: 0
  # Next, we write a form of the function that pattern matches the first
  # element to see if it is "true". If it is, we add 1.
  def count_sheeps([true | tail]), do: 1 + count_sheeps(tail)
  # All other elements will count as 0.
  def count_sheeps([_ | tail]), do: 0 + count_sheeps(tail)
end

My First Elixir App

When I first learned ruby over 6 years ago, my first ruby app was a cli blackjack game. If it was good enough to start learning ruby, it should be good practice for elixir as well.

The app is still a work in progress, but here is what I've done so far. I started by creating a new mix project which was probably a bit over kill. /shrug The first thing black jack needs is cards. So, I started by creating a Card Struct.
lib/card.ex

defmodule Card do
  defstruct suit: "", value: ""
end

And each card will be part of a Deck, so let's go ahead and create a Deck struct too. It was at this point, I felt like my Object Oriented Programming mindset was having an affect on the way I was writing elixir, but I kept going.

lib/deck.ex

defmodule Deck do
  # I used Module constants to specify the different suits and the card values.
  @suits [:heart, :diamond, :club, :spade]
  @values ["2", "3", "4", "5", "6", "7", "8", "9", "10", "J", "Q", "K", "A"]

  # To generate the deck, we flat_map the @suits List using the shorthand
  # function syntax to pass the suit into the `Deck.build_suit/1` function.
  # Then, the List returned from the flat_map is shuffled using `Enum.shuffle`
  def generate do
    @suits
    |> Enum.flat_map(&(build_suit(&1)))
    |> Enum.shuffle()
  end

  # the `Deck.build_suit/1` function maps over the @values List and creates
  # %Card structs using the given suit and card value.
  defp build_suit(suit) do
    @values |> Enum.map(fn (value) -> %Card{ suit: suit, value: value } end)
  end
end

Not a bad start. However, I spun my wheels trying to figure out how I would store the state of the game, and handle the initial deal. I was finally able to scrap together something that worked, but it's definitely subject to change.

defmodule Game do
  # I figured I could use a %Game struct to store the players and the current game's cards.
  # This will allow me to keep up with what a player's hand is as well as what
  # cards are still in play.
  defstruct players: [%Player{name: "player_one"}, %Player{name: "dealer"}], cards: Deck.generate()

  # With recursion on my mind from the earlier CodeWar Challenge, I created a
  # recursive deal function that would deal cards from the deck until each play
  # had their initial 2 cards.
  def deal(game) do
    cond do
      # The first conditional checks to see if all players have 2 cards
      Game.cards_dealt(game.players) -> game
      # The catch all conditional will deal a card to the first player in the
      # %Game struct then call deal again.
      true -> game |> deal_card(hd(game.players)) |> deal
    end
  end

  # deal_card/2 handles a couple of things.
  # 1. We pattern match the first `card` from the %Game.cards and the rest of
  # the cards. This essentially pulls a card from the deck.
  # 2. We update the %Game.players by giving the first `card` to the given player.
  # 3. Finally, we update the %Game struct cards to the `tail` from the original game argument.
  def deal_card(%{cards: [card | cards]} = game, player) do
    game
    |> update_players(Player.add_cards(player, card))
    |> case do
      game -> %{ game | cards: cards}
    end
  end

  def cards_dealt(players) do
    Enum.reduce(players, 0, fn player, acc -> acc + length(player.hand) end) == length(players) * 2
  end

  defp update_players(game, player) do
    players = game.players |> Enum.filter(fn (p) -> p.name != player.name end)

    # ++/2 is slower, but it makes it easier to deal the cards
    %{ game | players: players ++ [player]}
  end
end

I'd love to hear any thoughts about how to handle this better. You can drop a comment down below, or open up a pull request at https://github.com/basicBrogrammer/blackjack_cli. Thanks for tuning in and I'll see ya tomorrow.

Follow Me @

Twitter | Instagram

Round 1 Day 3

Jeremy Ward 😎🤓 — Mon, 15 Feb 2021 02:12:29 +0000

Keep Moving Forward

Three days ago I started the #100DaysOfCode Challenge, and today I finished elixirschool.com basics for elixir. This feels great because I started those basics over a year ago and stopped.

Quick TL;DR; for today.

Testing

ExUnit is built in to elixir, so I'll prolly be using that for my testing framework.
Test Mocks. The elixir community has an interesting take on mocking. The whole idea revolves around using "mocks" as a noun and not a verb. The concept is to keep parts of the code isolated and easier to test.
If you want to read more, check out the original blog post (here)[http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-contracts/]

Comprehensions

Generators:
- are neato
- multiple generators can be used at a time
Filters can be added to generators as you iterate over an Enum
- Ex. is_even => for x <- 1..10, is_even(x), do: x

Strings

Prolly never gonna need to use Graphemes or Codepoints

Time

Time.utc_now returns a "Time Struct" ~T[19:39:31.056226]
Date.utc_today returns a "Date Struct" ~D[2021-02-15]
NaiveDateTime feels .... useless. Its Date + Time with no timezone /shrug
I'll prolly most likly use DateTime instead.

Custom Mix Tasks

Are located in lib/mix/tasks/*.ex
When creating a Task you have to use the macro use Mix.Task
Mix tasks do not autoload dependencies

iEX Helpers (cool things about the REPL)

Tab autocomplete
.iex.exs is a local file to configure the repl
h Module or Function renders the docs
r Module will recompile the module

Tada. Day 3. Fin.
If you want to reach out, you can find me on (The Tweeters)[https://twitter.com/basicbrogrammer]

Round 1 Day 1

Jeremy Ward 😎🤓 — Sat, 13 Feb 2021 02:06:38 +0000

TIL

Currently, during the 100DaysOfCode Challenge, I'm learning elixir. I'll be documenting everything I learn or build as I go. I'm starting off with learning the elixir basics at ElixirSchool.

Basics

Everything is truthy except for false and nil
Booleans are atoms (:true, :false)
Modules are atoms
You can access erlang libraries using atoms
Aka atoms are important :)
Strings use double quotes
No modulo operator, but there are the div and rem functions.
Each basic type has a rank :/
- number < atom < reference < function < port < pid < tuple < map < list < bistring
- I'll never memorize this lawl
String interpolation "hello #{world}" or "hello " <> "world" ... Pretty Basic.

Collections

Lists
- Mixed types
- Not unique
- Linked List → faster to prepend than append > In computer science, a linked list is a linear collection of data elements whose order is not given by their physical placement in memory. Instead, each element points to the next. It is a data structure consisting of a collection of nodes that together represent a sequence.
- List concat ++/2 - cool
- List sub --/2 - cool cool
- Head/Tail - cool cool cool
- By pattern matching [head | tail] = list #=> head is the first element. the tail will be all the others
- hd list #=> returns the first element
- tl list #=> returns all elements after the first
Tuples
- Stored with a set amount of memory
- Access = fast; modification = slow
- Common for return info from function
Keyword lists
- commonly used to pass options to functions
Maps
- The Go-to key-value store
- Similar to ruby's hash
- Updating syntax is cool?
- useMap.put/3 to create a new key

Enum

Not much to go over here if you are familiar with any other languages Enum methods

Pattern Matching

The Holy Grail of Elixir
If you ask any dev what they love about elixir chances are they will mention pattern matching
Curveball = is actually a match operator similar to the equals sign in algebra :exploding-head:
[1| tail] = list #=> tail has not been matched so it binds to the last elements of the list

Control Structures

if and unless => straight forward
case/2
- Similar to switch(in javascript) or case (ruby) except it uses pattern matching
- _ is a catch all like default in JavaScript
Cond
- Used for matching multiple cases similar to an else if
With
- This one is bit trickier coming from other languages
- Can be used to replace multiple case statements

Want to crosspost to dev.to? There's a GitHub action for that.

Jeremy Ward 😎🤓 — Mon, 25 Jan 2021 20:35:28 +0000

If a tree falls in the woods, does it make a sound?

The internet is much like a forest with content and sites being like trees. There are thousands of trees growing in the forest off the beaten path that no one knows about. If you want your site or content to be discovered, the easiest way is to plant your tree close to the main trail.

Over the last 6 years of Software Development, I've learned a lot, but I've never shared it outside of my full-time job. If there's not an easy way for people to find the blogs I put out, then I'm still not sharing my thoughts with others. This is where sites like dev.to and hashnode come into play. I can write the markdown for my blog posts in vim then crosspost to other blog distribution platforms. I definitely didn't want to copypasta all my content every time, so I've decided to automate this process and open-source it.

Let's go over the code.
Let's take a look at how to use the GitHub Action.

DaCode

The first order of business is to find out if your last commit contains articles.

In order to do so, we first require two inputs from the GitHub workflow: github-token & content-dir. These two arguments will be retrieved using the @actions/core package. The github-token argument will be used to initiate an Octokit Rest client using the @actions/github package. We can use this instance to request the commit data. Once we have the response, all we have to do is iterate over the list of files and see if the filename match a given content directory (from the content-dir argument).

import * as core from '@actions/core';
import * as github from '@actions/github';

export const getFiles = async (): Promise<string[]> => {
  const octokit = github.getOctokit(core.getInput('github-token'));

  const commit = await octokit.repos.getCommit({
    ...github.context.repo,
    ref: github.context.sha,
  });

  return (commit?.data?.files || [])
    .map((file: any) => file.filename)
    .filter((filename: string) => filename.includes(core.getInput('content-dir')));
};

If this code finds markdown files, we will cycle through each file, sending it into a publish function.
We will use Node's file system readFileSync function to read the file into memory. Then, use the @github-docs/frontmatter package to parse the markdown so we can checkout the frontmatter which is just the "data" at the top of markdown files.

If the frontmatter indicates the post is published, we can go ahead and start crossposting.
Let's have a look at the current version of the publish function.

import * as core from '@actions/core';
import * as fs from 'fs';
import devTo from './dev-to';

const frontmatter = require('@github-docs/frontmatter');

const logResponse = async (title: string, destination: string, publishCallback: Promise<any>): Promise<void> => {
  const {status} = await publishCallback;
  console.table({title, destination, status});
};

const publish = async (path: string): Promise<void> => {
  try {
    const markdown = fs.readFileSync(`./${path}`, 'utf8');
    const {data} = frontmatter(markdown);

    if (data.published) {
      if (core.getInput('dev-to-token').length > 0) {
        logResponse(data.title, 'Dev.to', devTo.publish(markdown));
      }
    } else {
      console.log(`Article ${data.title} NOT published. Skipping.`);
    }
  } catch (err) {
    core.setFailed(err.message);
  }
};

export default publish;

Currently, I am only crossposting to dev.to, but soon I want to update the GitHub Action to crosspost to hashnode.com as well. 🤙

To crosspost to dev.to, the publish function passes the markdown into the publish method on an authenticated instance of DevTo.
The devTo.publish method uses the auth token and node-fetch to POST your markdown to dev.to's api and boom it's done.

And here is the dead simple code for our DevTo class:

import fetch from 'node-fetch';
import * as core from '@actions/core';

class DevTo {
  token: string;
  constructor() {
    this.token = core.getInput('dev-to-token');
  }

  async publish(body_markdown: string): Promise<any> {
    const body = {
      article: {
        body_markdown,
      },
    };

    return fetch('https://dev.to/api/articles', {
      method: 'post',
      body: JSON.stringify(body),
      headers: {
        'Content-Type': 'application/json',
        'api-key': this.token,
      },
    }).then((response: any) => response.json());
  }
}

export default new DevTo();

That's really it. That's all the code needed to keep you from having to copy and paste your blog markdown to multiple distributors!

DaAction

As I was writing this code, I was like why don't I make it a GitHub Action and share it with anyone that would like to use it. So I did 😎.

Let's take a look at how you can use this action in your GitHub blog repo.

Inside your GitHub repo, add a workflow file. Mine is .github/workflows/crosspost.yml.

I'm using nuxt's content module to build my blog, and have it configured to look for blog posts in the ./content/articles/ directory. So, let's tell our action to only run when a file is changed in that directory:

name: CrossPost

on:
  push:
    paths:
    - './content/articles/*'

Next, we need to start writing the yaml for the job itself. First, we will check out the code:

jobs:
  crosspost:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Code
      uses: actions/checkout@v2

Super simple.

Next step will be to run the crosspost-markdown action and pass in the necessary arguments (content-dir and dev-to-token). These can be set in the secrets section of your repo's settings.

jobs:
  crosspost:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Code
      uses: actions/checkout@v2

    - uses: basicBrogrammer/crosspost-markdown@v0.1.0 # remember to see what the latest version is 8)
      with:
        content-dir: './content/articles/'
        dev-to-token: ${{ secrets.DEV_TO }}
        github-token: ${{ secrets.GITHUB_TOKEN }}

All done. Now when you push to your repo the GitHub Action will run and if you have any new blog posts it will publish them to dev.to.

Cache me on Tweeter, HowBowDat? Click Me. I dare you.

When a simple React context gets out of hand.

Jeremy Ward 😎🤓 — Mon, 25 Jan 2021 10:10:53 +0000

TL;DR:

Sometimes what you think is a K.I.S.S. solution turns into Frankenstein.
If you find yourself wanting to use a useEffect inside a React context, think twice.
More importantly, be careful with useEffects that depend on global state.
Kent C Dodds has some clean ideas about setting up the React Context API.
I will prolly default to a useReducer in my "app" contexts from now on.

Let's start simple.

My team started a new React app and we wanted see what it would be like to use the React Context API, simple useState. We also wanted to treat each context as "boxes" of similar data.

Let's assume that our app has grown to need 2 contexts:

1 for "Auth"
1 for the "Timeline" [for lack of better naming]

  const AuthContext = React.createContext();

  const AuthContextProvider = ({ children }) => {
    const [user, setUser] = useState();
    const [isLoggedIn, setIsLoggedIn] = useState();

    const state = { user, isLoggedIn };

    return (
      <AuthContext.Provider value={{ state, setUser, setIsLoggedIn }}>
        {children}
      </AuthContext.Provider>
    );
  };

The AuthContext contains state associated with authentication. When a user signs in, setIsLoggedIn(true) & setUser({email, username}) functions are both called. This will change the state of the AuthContext and can trickle through the app.

const TimelineContext = React.createContext();

const TimelineContextProvider = ({ children }) => {
  const [posts, setPosts] = useState([]);
  // For the purposes of this blog, selectedPost will be used to display
  // the "show page"
  const [selectedPost, setSelectedPost] = useState(null);
  // And let's imagine we want to do the same thing for a comment.
  const [selectedComment, setSelectedComment] = useState(null);

  const state = { posts, selectedPost, selectedComment };

  return (
    <TimelineContext.Provider
      value={{ state, setPosts, setSelectedPost, setSelectedComment }}
    >
      {children}
    </TimelineContext.Provider>
  );
};

The TimelineContext will maintain the state for our timeline including a list of posts, a selectedPost, and a selectedComment.

These are pretty simple, right?

One issue with this that immediately pops out is the return value of each context. Currently, we can see as we add new state the return value grow pretty quickly.

Let's go ahead and solve that in the TimelineContext.

  const TimelineContextProvider = ({ children }) => {
    const [posts, setPosts] = useState([]);
    const [selectedPost, setSelectedPost] = useState(null)
    const [selectedComment, setSelectedComment] = useState(null)

    const state = { posts, selectedPost, selectedComment };
    const actions = { setPosts, setSelectedPost, setSelectedComment }

    return (
      <TimelineContext.Provider value={{ state, actions}}>
        {children}
      </TimelineContext.Provider>
    );
  };

Ok. That helps a bit. We have constrained the return object to state & actions.

Another annoyance would be if this context grows in size. The more useStates we add, the harder it could be to manage. This was the idea of having multiple contexts. We can have a clear separation of concerns.

NEW REQUIREMENT!

Now we want to set a selected post and comment within our application. If the comment is dependent on the post, we will also need to nullify the selectedComment when a new post is selected.

This is fairly simple. We can just throw in a useEffect and boom.

  const TimelineContextProvider = ({ children }) => {
    const [posts, setPosts] = useState([]);
    const [selectedPost, setSelectedPost] = useState(null)
    const [selectedComment, setSelectedComment] = useState(null)

    const state = { posts, selectedPost, selectedComment };
    const actions = { setPosts, setSelectedPost, setSelectedComment }

    useEffect(() => {
      setSelectedComment(null)
    }, [selectedPost])

    return (
      <TimelineContext.Provider value={{ state, actions}}>
        {children}
      </TimelineContext.Provider>
    );
  };

More Modification!!!

Now let's say for testing purposes we want to add initial{SelectedPost and SelectedComment}. Stupid simple. Or is it?

The way we currently have it set up, the useEffect will set our initialSelectedComment to null on the first render. OOOO no a side useEffect!!!

So our context then turns into:

const TimelineContextProvider = ({
  initialSelectedPost,
  initialSelectedComment,
  children
}) => {
  const [posts, setPosts] = useState([]);
  const [selectedPost, setSelectedPost] = useState(initialSelectedPost);
  const [selectedComment, setSelectedComment] = useState(
    initialSelectedComment
  );

  const state = { posts, selectedPost, selectedComment };
  const actions = { setPosts, setSelectedPost, setSelectedComment };

  useEffect(() => {
    if (initialSelectedPost != initialSelectedComment) {
      setSelectedComment(null);
    }
  }, [selectedPost]);

  return (
    <TimelineContext.Provider value={{ state, actions }}>
      {children}
    </TimelineContext.Provider>
  );
};

This may not be a huge issue, but it will cause us to have to think about any consequences that may occur just from changing state.

Single Source of Global Truth

One gripe from the team has been "well which use{X}Context do I use in the component?". Both the AuthContext and TimelineContext are part of the global state so one solution would be to just combine them, and separate the domains inside the state object. Let's start by solving that issue.

const AppContextProvider = ({
  initialSelectedPost,
  initialSelectedComment,
  children
}) => {
  const [user, setUser] = useState();
  const [isLoggedIn, setIsLoggedIn] = useState();
  const [posts, setPosts] = useState([]);
  const [selectedPost, setSelectedPost] = useState(initialSelectedPost);
  const [selectedComment, setSelectedComment] = useState(
    initialSelectedComment
  );

  const state = {
    auth: { user, isLoggedIn },
    timeline: { posts, selectedPost, selectedComment }
  };

  const actions = {
    setUser,
    setIsLoggedIn,
    setPosts,
    setSelectedPost,
    setSelectedComment
  };

  useEffect(() => {
    if (initialSelectedPost != initialSelectedComment) {
      setSelectedComment(null);
    }
  }, [selectedPost]);

  return (
    <AppContext.Provider value={{ state, actions }}>
      {children}
    </AppContext.Provider>
  );
};

Not a huge win IMO, but now the team is happier.

Revelio Side Effects

After working with React hooks for a year, I've come to the conclusion that useEffect in a context is probably a bad idea. (I'd love to see examples where you've made this work BTW).

A more concrete rule that I've landed on is that we should not have a useEffect in our app that relies on global state. I kind of see this a sharp knife that could easily poke your eye out. It raises the barrier to work on a project for people that don't work in the frontend day in and day out. Even for someone working in the codebase, it's something they always have to keep in the back of their mind. "If I change {X}, this callback will run, and do I need to modify it?".

My solution to this is to always (well prolly 95% of the time) use useReducer in global state and to never have a useEffect depend on a piece of global state.

Let's go!

Initial State

First, we will start with our app's initial state.

const initialState = {
  auth: { user: null, isLoggedIn: false },
  timeline: { posts: [], selectedPost: null, selectedComment: null }
};

Well, that was easy enough! Defining our initial state lets us see all of our global state at a glance. Any time we want to add something to our global state, we can start by adding a sensible default to our initialState object. For example, isLoggedIn is initially false, and posts is initially an empty array.

Reducery, my dear Watson

My favorite part of the reducer pattern is you can think of each action in your reducer as single interactions with your app. These interactions can either be network requests or UserEvents. When setting up an action, I ask "What happens to the state when {X} occurs". Then, you just dispatch that action with the correct payload and boom boom boom. Done! Now, if the same interaction occurs in 2 places, you don't have to open the other component and remember the logic; you just dispatch the action.

For the auth part of our context, we have 2 interactions: sign in and logout.

Let's take a look at the code for this.

const ActionTypes = {
  SET_USER: "set-user",
  LOGOUT_USER: "logout-user",
}
const reducer = (state, action) => {
  switch (action.type) {
    case ActionTypes.SET_USER: {
      return {
        ...state,
        auth: { ...state.auth, user: action.payload, isLoggedIn: true }
      };
    }
    case ActionTypes.LOGOUT_USER: {
      return {
        ...state,
        auth: { ...state.auth, user: null, isLoggedIn: false }
      };
    }
    ...
  }
};

Wow, that's K.I.S.S. :D

Now we don't have to remember to call setUser and setIsLoggedIn, we just dispatch the corresponding action for the given interaction.

Next up, let's add actions for the timeline state.

const ActionTypes = {
  ...,
  ADD_POSTS: "add-posts",
  SELECT_POST: "select-post",
  SELECT_COMMENT: "select-comment"
};

const reducer = (state, action) => {
  switch (action.type) {
    ...,
    case ActionTypes.ADD_POSTS: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          posts: [...state.timeline.posts, ...action.payload]
        }
      };
    }
    case ActionTypes.SELECT_POST: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          selectedPost: action.payload,
          selectedComment: null
        }
      };
    }
    case ActionTypes.SELECT_COMMENT: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          selectedComment: action.payload
        }
      };
    }
    ...,
  }
};

You may not have realized it, but the SELECT_POST action solves the useEffect side effect issue! If you remember, we had a useEffect in our original context that would nullify the selectedComment when the selectedPost changes. Now, we can set an initialSelectedPost & initialSelectedComment without worrying about the useEffect firing off; eliminating the need for an if state just for testing purposes.

The New Context

The last piece of the puzzle is providing our new reducer to our app via a React Context.

const AppProvider = ({ initialState, reducer, children }) => {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <AppContext.Provider value={{ state, dispatch }}>
      {children}
    </AppContext.Provider>
  );
};

Well, that's a lot cleaner. My team works in a Rails monolith which is why I've decided to have initialState and the reducer be props for the AppProvider. This approach allows us to use the same provider for any React app that we decide to create.

Conclusion

Currently, this is my favorite way to [with some extra magic I'll blog about later] manage global state in a React app.

No added dependencies.
No side effects on global state that have to be memorized.
Each interation is mapped to a single encapsulated action.

Putting it all together.

const initialState = {
  auth: { user: null, isLoggedIn: false },
  timeline: { posts: [], selectedPost: null, selectedComment: null }
};

const ActionTypes = {
  SET_USER: "set-user",
  LOGOUT_USER: "logout-user",
  ADD_POSTS: "add-posts",
  SELECT_POST: "select-post",
  SELECT_COMMENT: "select-comment"
};

const reducer = (state, action) => {
  switch (action.type) {
    case ActionTypes.SET_USER: {
      return {
        ...state,
        auth: { ...state.auth, user: action.payload, isLoggedIn: true }
      };
    }
    case ActionTypes.LOGOUT_USER: {
      return {
        ...state,
        auth: { ...state.auth, user: null, isLoggedIn: false }
      };
    }
    case ActionTypes.ADD_POSTS: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          posts: [...state.timeline.posts, ...action.payload]
        }
      };
    }
    case ActionTypes.SELECT_POST: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          selectedPost: action.payload,
          selectedComment: null
        }
      };
    }
    case ActionTypes.SELECT_COMMENT: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          selectedComment: action.payload
        }
      };
    }
    default:
      return state;
  }
};

const AppProvider = ({ initialState, reducer, children }) => {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <AppContext.Provider value={{ state, dispatch }}>
      {children}
    </AppContext.Provider>
  );
};

You can find my random tech ramblings on tweeter @basicbrogrammer

References

Shout out to Kent Dodds. He has some killer React patterns on his blog. Check it out.

The docs on userReducer from React

When a simple React context gets out of hand.

Jeremy Ward 😎🤓 — Tue, 22 Dec 2020 02:30:18 +0000

TL;DR:

Sometimes what you think is a K.I.S.S. solution turns into Frankenstein.
If you find yourself wanting to use a useEffect inside a React context, think twice.
More importantly, be careful with useEffects that depend on global state.
Kent C Dodds has some clean ideas about setting up the React Context API.
I will prolly default to a useReducer in my "app" contexts from now on.

Let's start simple.

My team started a new React app and we wanted see what it would be like to use the React Context API, simple useState. We also wanted to treat each context as "boxes" of similar data.

Let's assume that our app has grown to need 2 contexts:

1 for "Auth"
1 for the "Timeline" [for lack of better naming]

  const AuthContext = React.createContext();

  const AuthContextProvider = ({ children }) => {
    const [user, setUser] = useState();
    const [isLoggedIn, setIsLoggedIn] = useState();

    const state = { user, isLoggedIn };

    return (
      <AuthContext.Provider value={{ state, setUser, setIsLoggedIn }}>
        {children}
      </AuthContext.Provider>
    );
  };

const TimelineContext = React.createContext();

const TimelineContextProvider = ({ children }) => {
  const [posts, setPosts] = useState([]);
  // For the purposes of this blog, selectedPost will be used to display
  // the "show page"
  const [selectedPost, setSelectedPost] = useState(null);
  // And let's imagine we want to do the same thing for a comment.
  const [selectedComment, setSelectedComment] = useState(null);

  const state = { posts, selectedPost, selectedComment };

  return (
    <TimelineContext.Provider
      value={{ state, setPosts, setSelectedPost, setSelectedComment }}
    >
      {children}
    </TimelineContext.Provider>
  );
};

The TimelineContext will maintain the state for our timeline including a list of posts, a selectedPost, and a selectedComment.

These are pretty simple, right?

One issue with this that immediately pops out is the return value of each context. Currently, we can see as we add new state the return value grow pretty quickly.

Let's go ahead and solve that in the TimelineContext.

  const TimelineContextProvider = ({ children }) => {
    const [posts, setPosts] = useState([]);
    const [selectedPost, setSelectedPost] = useState(null)
    const [selectedComment, setSelectedComment] = useState(null)

    const state = { posts, selectedPost, selectedComment };
    const actions = { setPosts, setSelectedPost, setSelectedComment }

    return (
      <TimelineContext.Provider value={{ state, actions}}>
        {children}
      </TimelineContext.Provider>
    );
  };

Ok. That helps a bit. We have constrained the return object to state & actions.

NEW REQUIREMENT!

Now we want to set a selected post and comment within our application. If the comment is dependent on the post, we will also need to nullify the selectedComment when a new post is selected.

This is fairly simple. We can just throw in a useEffect and boom.

  const TimelineContextProvider = ({ children }) => {
    const [posts, setPosts] = useState([]);
    const [selectedPost, setSelectedPost] = useState(null)
    const [selectedComment, setSelectedComment] = useState(null)

    const state = { posts, selectedPost, selectedComment };
    const actions = { setPosts, setSelectedPost, setSelectedComment }

    useEffect(() => {
      setSelectedComment(null)
    }, [selectedPost])

    return (
      <TimelineContext.Provider value={{ state, actions}}>
        {children}
      </TimelineContext.Provider>
    );
  };

More Modification!!!

Now let's say for testing purposes we want to add initial{SelectedPost and SelectedComment}. Stupid simple. Or is it?

The way we currently have it set up, the useEffect will set our initialSelectedComment to null on the first render. OOOO no a side useEffect!!!

So our context then turns into:

const TimelineContextProvider = ({
  initialSelectedPost,
  initialSelectedComment,
  children
}) => {
  const [posts, setPosts] = useState([]);
  const [selectedPost, setSelectedPost] = useState(initialSelectedPost);
  const [selectedComment, setSelectedComment] = useState(
    initialSelectedComment
  );

  const state = { posts, selectedPost, selectedComment };
  const actions = { setPosts, setSelectedPost, setSelectedComment };

  useEffect(() => {
    if (initialSelectedPost != initialSelectedComment) {
      setSelectedComment(null);
    }
  }, [selectedPost]);

  return (
    <TimelineContext.Provider value={{ state, actions }}>
      {children}
    </TimelineContext.Provider>
  );
};

This may not be a huge issue, but it will cause us to have to think about any consequences that may occur just from changing state.

Single Source of Global Truth

const AppContextProvider = ({
  initialSelectedPost,
  initialSelectedComment,
  children
}) => {
  const [user, setUser] = useState();
  const [isLoggedIn, setIsLoggedIn] = useState();
  const [posts, setPosts] = useState([]);
  const [selectedPost, setSelectedPost] = useState(initialSelectedPost);
  const [selectedComment, setSelectedComment] = useState(
    initialSelectedComment
  );

  const state = {
    auth: { user, isLoggedIn },
    timeline: { posts, selectedPost, selectedComment }
  };

  const actions = {
    setUser,
    setIsLoggedIn,
    setPosts,
    setSelectedPost,
    setSelectedComment
  };

  useEffect(() => {
    if (initialSelectedPost != initialSelectedComment) {
      setSelectedComment(null);
    }
  }, [selectedPost]);

  return (
    <AppContext.Provider value={{ state, actions }}>
      {children}
    </AppContext.Provider>
  );
};

Not a huge win IMO, but now the team is happier.

Revelio Side Effects

After working with React hooks for a year, I've come to the conclusion that useEffect in a context is probably a bad idea. (I'd love to see examples where you've made this work BTW).

My solution to this is to always (well prolly 95% of the time) use useReducer in global state and to never have a useEffect depend on a piece of global state.

Let's go!

Initial State

First, we will start with our app's initial state.

const initialState = {
  auth: { user: null, isLoggedIn: false },
  timeline: { posts: [], selectedPost: null, selectedComment: null }
};

Reducery, my dear Watson

For the auth part of our context, we have 2 interactions: sign in and logout.

Let's take a look at the code for this.

const ActionTypes = {
  SET_USER: "set-user",
  LOGOUT_USER: "logout-user",
}
const reducer = (state, action) => {
  switch (action.type) {
    case ActionTypes.SET_USER: {
      return {
        ...state,
        auth: { ...state.auth, user: action.payload, isLoggedIn: true }
      };
    }
    case ActionTypes.LOGOUT_USER: {
      return {
        ...state,
        auth: { ...state.auth, user: null, isLoggedIn: false }
      };
    }
    ...
  }
};

Wow, that's K.I.S.S. :D

Now we don't have to remember to call setUser and setIsLoggedIn, we just dispatch the corresponding action for the given interaction.

Next up, let's add actions for the timeline state.

const ActionTypes = {
  ...,
  ADD_POSTS: "add-posts",
  SELECT_POST: "select-post",
  SELECT_COMMENT: "select-comment"
};

const reducer = (state, action) => {
  switch (action.type) {
    ...,
    case ActionTypes.ADD_POSTS: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          posts: [...state.timeline.posts, ...action.payload]
        }
      };
    }
    case ActionTypes.SELECT_POST: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          selectedPost: action.payload,
          selectedComment: null
        }
      };
    }
    case ActionTypes.SELECT_COMMENT: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          selectedComment: action.payload
        }
      };
    }
    ...,
  }
};

The New Context

The last piece of the puzzle is providing our new reducer to our app via a React Context.

const AppProvider = ({ initialState, reducer, children }) => {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <AppContext.Provider value={{ state, dispatch }}>
      {children}
    </AppContext.Provider>
  );
};

Conclusion

Currently, this is my favorite way to [with some extra magic I'll blog about later] manage global state in a React app.

No added dependencies.
No side effects on global state that have to be memorized.
Each interation is mapped to a single encapsulated action.

Putting it all together.

const initialState = {
  auth: { user: null, isLoggedIn: false },
  timeline: { posts: [], selectedPost: null, selectedComment: null }
};

const ActionTypes = {
  SET_USER: "set-user",
  LOGOUT_USER: "logout-user",
  ADD_POSTS: "add-posts",
  SELECT_POST: "select-post",
  SELECT_COMMENT: "select-comment"
};

const reducer = (state, action) => {
  switch (action.type) {
    case ActionTypes.SET_USER: {
      return {
        ...state,
        auth: { ...state.auth, user: action.payload, isLoggedIn: true }
      };
    }
    case ActionTypes.LOGOUT_USER: {
      return {
        ...state,
        auth: { ...state.auth, user: null, isLoggedIn: false }
      };
    }
    case ActionTypes.ADD_POSTS: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          posts: [...state.timeline.posts, ...action.payload]
        }
      };
    }
    case ActionTypes.SELECT_POST: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          selectedPost: action.payload,
          selectedComment: null
        }
      };
    }
    case ActionTypes.SELECT_COMMENT: {
      return {
        ...state,
        timeline: {
          ...state.timeline,
          selectedComment: action.payload
        }
      };
    }
    default:
      return state;
  }
};

const AppProvider = ({ initialState, reducer, children }) => {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <AppContext.Provider value={{ state, dispatch }}>
      {children}
    </AppContext.Provider>
  );
};

You can find my random tech ramblings on tweeter @basicbrogrammer

References

Shout out to Kent Dodds. He has some killer React patterns on his blog. Check it out.

The docs on userReducer from React

Hello, Dev.to

Jeremy Ward 😎🤓 — Sun, 04 Aug 2019 13:17:52 +0000

I have been a dev for ~5 years now. I went from physics major to The Iron Yard bootcamp grad and 1 month later I was a developer. A few weeks ago I realized I didn't have a "portfolio". So, I wanted to find a way to get my thoughts about deving out to the world.

I'm not a great writer (hence physics major :D ) so blogs never really appealed to me, but why not give it a shot. I thought about creating a personal site, but then, I was like "why not just use dev.to + twitter + youtube as my blog?" Seems simple enough. 8)

I'm a Ruby on Rails and EmberJS dev by trade, but over the next few months I'm going to dive into the world of Elixir. Let's see how this journey turns out.

Jeremy aka @basicbrogrammer