DEV Community: edensongjbs

Redux-Thunk Testing with Chuck Norris

edensongjbs — Mon, 16 Nov 2020 21:58:01 +0000

Asynchronous Testing Techniques with Jest

When I'm working on a personal React project, I'm always tempted to cut to the chase and get right to coding the fun stuff: seeing my app concept come to life. I'll try and get a quick interface up and running, verify that it's behaving as expected in the browser and call it a day. Often times (especially with a simple project), this is fine. There are those other times when things break unexpectedly and I'll be stuck digging back through my code in painstaking detail trying to remind myself how a particular piece of state is being updated or how a particular component is being used, all the while cursing myself for not starting out the project with a more rigorous test-driven approach.

Test-driven development (TDD) always feels like a lift in the beginning stages of a project, but it can end up saving so much time down the road. TDD forces us to do the mental work up front. In the context of a React project, this means more rigorously planning the different components and their responsibilities, how these components will use state and how that state will be updated. It lets us determine what is essential to the structure and function of our app, while abstracting away the implementation details that we can refactor as we go. It provides us a failsafe, letting us know immediately if we modified something that's going to break our application. Beyond this, it makes collaboration and communication easier in the long-run. Being able to successfully test an app requires that we are able to clearly understand, anticipate, codify, and communicate how the app should be working.

Challenges of Asynchronous Testing

For testing in React, I've primarily been using the Jest testing framework (which comes pre-installed in any new project created with npx create-react-app). The API Docs are well-written and the syntax (describe, test, expect) felt quite familiar to me coming from Rspec in the Ruby language. Nevertheless, testing JavaScript poses some interesting challenges, especially when it comes to handling asynchronous functions. While there are endless examples of those in any given JS/React project, I'm going to focus this article on how to do asynchronous testing with Redux-Thunk action creators, something I've found particularly challenging to wrap my head around.

If you're unfamiliar with Redux-Thunk, I'd recommend checking out this post. In short, Redux-Thunk allows for dispatching an asynchronous action, by letting you call an action creator that returns a function (instead of a simple action object), into which the store's dispatch function is passed. The passed dispatch function is then used to dispatch standard Redux action objects from within the function (either synchronously or asynchronously).

To help me demonstrate some Redux-Thunk testing techniques in Jest, I'll call upon everyone's favorite hyperbolic tough guy, Chuck Norris, to lend a hand...

The App

I've built an exceedingly simple React/Redux app to demo our tests (you can find the GitHub repo here). In short, the app is a front-end for the ChuckNorris.io API, where the user will click a button and a random Chuck Norris
"fact" will be displayed on the screen. Important to our implementation is the detail that the user can only fetch up to 5 Chuck Norris "facts" before being cut off and being forced to refresh the page. Though it's overkill in the extreme to be using Redux for such a simple app, it seems appropriately in the spirit of Chuck Norris and certainly a good opportunity to demo testing techniques without too many complicating factors.

Here's a step by step for following along at home:

Installing Dependencies

After creating a new react app (via npx create-react-app chuck-norris-jokes), you'll need to install the following dependencies to get things set up:

npm install --save-dev fetch-mock ( to mock the API fetch request so that we can test our app in isolation )
npm intall --save-dev node-fetch ( since the tests will be using the fetch API without the browser )
npm install redux react-redux redux-thunk ( since the app uses Redux and Redux-Thunk)

Setting Up the App

The Components

I've set up the App component to render two components: a FetchButton component, that the user will click in order to fetch the new Chuck Norris "fact" and the Joke component, which will display the fact if it is successfully fetched. The Joke component is purely presentational and receives the joke passed down in props from our App component. However, the FetchButton component has access to our Redux store and will invoke our Redux-Thunk action creator fetchJoke, when the button is clicked.

from ./src/App.js

import { connect } from 'react-redux'
import FetchButton from './FetchButton'
import Joke from './Joke'

class App extends React.Component {
  render() {
    return (
      <div className="App">
        <h1>Get a new Chuck Norris Joke</h1>
        {!this.props.tooMany
          ?  <><FetchButton/><Joke joke={this.props.joke}/></>
          :  <h3>That's Too Many Chuck Norris Jokes.  Please refresh!</h3>
        }
      </div>
    )
  }
}

const mapStateToProps = state => ({tooMany: state.tooMany, joke: state.joke})

export default connect(mapStateToProps)(App)`

The Reducers

I set up our root reducer to manage 3 distinct pieces of state: joke (the joke fetched from the API), jokeCount (the number of jokes that have been fetched from the API since the program launched, which cannot exceed 5), and tooMany (initially set to false, but set to true once the user attempts to fetch more jokes than allowed).

from ./src/reducers/joke.js

const joke = (state=null, action={}) => {
    switch (action.type) {
        case ('SET_JOKE'):
            return action.payload
        default:
            return state
    }
}

export default joke

from ./src/reducers/jokeCount.js

const jokeCount = (state=0, action={}) => {
    switch (action.type) {
        case ('INC_JOKE_COUNT'):
            return state+1
        default:
            return state
    }
}

export default jokeCount

from ./src/reducers/tooMany.js

const tooMany = (state=false, action={}) => {
    switch (action.type) {
        case ('TOO_MANY'):
            return true
        default:
            return state
    }
}

export default tooMany

from ./src/reducers/index.js

import { combineReducers } from 'redux'
import joke from './joke'
import jokeCount from './jokeCount'
import tooMany from './tooMany'


export default combineReducers({
    joke, jokeCount, tooMany
})

Configuring and Connecting the Store to our App

You can refer to the Redux-Thunk API docs for additional details on configuring the Redux-Thunk middleware, but make sure to export your configured store so that it can be accessed for both testing and development/production purposes. This is how I approached my storeFactory function.

from ./src/configureStore.js

import { createStore, applyMiddleware } from 'redux'
import ReduxThunk from 'redux-thunk'
import rootReducer from './reducers'

const storeFactory = (initialState) => {
    const middleware = [ReduxThunk]
    const createStoreWithMiddleware = applyMiddleware(...middleware)(createStore)
    return createStoreWithMiddleware(rootReducer, initialState)
}

export default storeFactory

You'll need to pass your store to your App component and also import the storeFactory function into your test.js file, where you will use it to create a mock store for your tests.

in ./src/index.js (creating a store for the app)

import store from './configureStore'

ReactDOM.render(
  <React.StrictMode>
    <Provider store={store()}><App /></Provider>
  </React.StrictMode>,
  document.getElementById('root')
)

Setting Up the Tests

At the heart of our app's functionality, is a single asynchronous action creator called fetchJoke, which returns a function into which the store's dispatch function is passed. This function will be responsible for dispatching other actions to our reducer. It's very important for us to think through the logic of how these actions will be dispatched, as certain actions may be synchronous and others asynchronous, which will affect how we must structure our tests.

Let's jump now to setting up those tests. For the purpose of this article, we're mostly concerned with setting up tests for our fetchJoke action creator. This is technically an integration test, since it will be utilizing our reducers as well, but I decided to place it in our ./src/actions directory and name it accordingly since its primary purpose is to test the action creator, the main logical component of our app.

Here are our test descriptions:

from ./src/actions/index.test.js

describe('fetchJoke action creator', () => {

    test('fetches a joke on the first attempt', () => {

    })
    test('fetches a joke when the limit has almost been reached', () => {

    })
    test('fetches a joke when the limit will be exceeded', () => {

    })
    test('fetches a joke when the limit has already been exceeded', () => {

    })
  })

Before we can code out the test blocks, we need to do some preliminary setup in our ./src/actions/index.test.js file:

Step 1 - Create a Test Store

Since we have already created a storeFactory function, we can just import that and use it to create a mock store for our tests.

in .src/actions/index.test.js (creating a mock store for our tests)

import createTestStore from '../configureStore'

Step 2 - Mocking the API Call

While our actual app relies upon fetching values from the ChuckNorris.io API, we want to test our app in isolation. So, we'll need to sub in a mock fetch in place of the real fetch in the action creator. We can do this purely in the test file without making any changes to our actual action creator code (ie) the app never needs to know that it's not getting a real API response). We can do this with a useful tool call fetch-mock (that we've already installed as a dependency). You can configure it like this:

in ./src/actions/index.test.js

import fetchMock from 'fetch-mock'
import { fetchJoke } from './'

const url = 'https://api.chucknorris.io/jokes/random'

describe('fetchJoke action creator', () => {
    //Setting up our mock response
    beforeEach(() => {
      fetchMock.mock(url, {
          status: 200,
          value: 'Not a real Chuck Norris joke.'
      });
    })
    // Clearing the mock response.  Returning to default fetch behavior
    afterEach(() => {
      fetchMock.restore()
    })
...

Step 3 - Writing out the Test Blocks

To test each of our four conditions, we start by creating our test store and initializing it with a state to support the conditions that we're aiming to test. Here, you can see the appropriate initial state for each of our conditions:
from ./src/actions/index.test.js

test('fetches a joke on the first attempt', () => {

      const store = createTestStore()

    })
    test('fetches a joke when the limit has almost been reached', () => {

      const store = createTestStore({jokeCount:4, joke:""})

    })
    test('fetches a joke when the limit will be exceeded', () => {

      const store = createTestStore({jokeCount:5, joke:""})

    })
    test('fetches a joke when the limit has already been exceeded', () => {

      const store = createTestStore({tooMany:true, joke:""})

    })

We can also write out our expectations for each of the four test cases:

from ./src/actions/index.test.js

test('fetches a joke on the first attempt', () => {

      const store = createTestStore()
      expect(newState.joke).toBe('Not a real Chuck Norris joke.')
    })
    test('fetches a joke when the limit has almost been reached', () => {

      const store = createTestStore({jokeCount:4, joke:""})
      expect(newState.joke).toBe('Not a real Chuck Norris joke.')
    })
    test('fetches a joke when the limit will be exceeded', () => {

      const store = createTestStore({jokeCount:5, joke:""})
      expect(newState.joke).toBe('cutting you off');
    })
    test('fetches a joke when the limit has already been exceeded', () => {

      const store = createTestStore({tooMany:true, joke:""})
      expect(newState.joke).toBe('no more jokes')
    })

There are two things to note here:

Firstly, these tests are not yet ready since we haven't actually dispatched our action creator. Unless the tests are expecting the state to be unchanged (ie) our store's initial state), these tests will fail.

Secondly, note how specific the expectation statements are for each case. There are specific strings that will need to be returned in our reducer in order to get these tests to pass. I wanted to make doubly sure that the logic in our action creator is behaving as expected, so I'm asking for a different joke state depending on whether the limit is being reached on this call or had already been reached on a previous call (ie) whether the tooMany piece of state had already been toggled from false to true). This is fussy, but I thought it was important for ensuring that we cover all our cases and our action creator is acting predictably for each condition.

Before our tests are finished, we need to determine what is happening between our store initialization and our expectation. It's very important for us to have a clear sense of how our async action creator will be working, because this will affect where we place our expect statement. In the case of our fetchJoke action creator, different conditions will cause our actions to be synchronous or asynchronous.

Why is this exactly?

We want our action creator to first check the tooMany piece of state before making a fetch request to the API. It will first determine if the user has already reached the request limit. We'll also want to check a case where the jokeCount piece of state is at the limit, but the tooMany piece of state has not yet been toggled to true. In each of these cases, we want our app to NOT send a fetch request to the API, and instead dispatch a simple action object synchronously. However, In the event that the jokeCount IS under the limit set by our app, we will make the asynchronous fetch request to the server (via the fetch API), and dispatch the simple 'SET_JOKE' action object only after receiving a response from the server.

For our synchronous cases, we can simply setup our dispatch and expectation statements normally:

from ./src/actions/index.test.js

test('fetches a joke when the limit will be exceeded', () => {

      const store = createTestStore({jokeCount:5, joke:""})

      store.dispatch(fetchJoke())
      const newState = store.getState();
      expect(newState.joke).toBe('cutting you off')
    })
    test('fetches a joke when the limit has already been exceeded', () => {

      const store = createTestStore({tooMany:true, joke:""})

      store.dispatch(fetchJoke())
      const newState = store.getState();
      expect(newState.joke).toBe('no more jokes')
    })

However, for our asynchronous cases, we must set up our test so that our dispatch returns a Promise. We can place our expect statement inside a function that we pass the chained .then() function. The expect statement will run once the Promise has resolved.

from ./src/actions/index.test.js

test('fetches a joke on the first attempt', () => {

      const store = createTestStore();

      return store.dispatch(fetchJoke())
        .then(() => {
          const newState = store.getState();
          expect(newState.joke).toBe('Not a real Chuck Norris joke.')
        })
    })

IMPORTANT: In order for this to actually work, we must make sure that we actually set up our action creator to return a promise. Otherwise, we'll run into errors. Check out the action creator code below for reference.

If we make a mistake and set up the synchronous test block to run asynchronously, we'll run into the above error, where a Promise is not returned from our action creator, and there is no .then function to invoke. If we do the opposite and set up our asynchronous test block to run synchronously, it will simply jump to our expect statement before the asynchronous code has a chance to run and the test will (most likely) fail.

Step 4 - Coding Out the Action Creator

After defining the fetchJoke function, you can verify that all tests are currently failing. It's important for us to verify that the tests are failing as expected so that we don't wind up with faulty tests that can lead to us assuming our code is working properly when it isn't!

from ./src/actions/index.js

export const fetchJoke = () => { 

}

Here's the fully coded fetchJoke function for reference:

from ./src/actions/index.js

export const fetchJoke = () => { 
    const max = 5 // Total number of jokes allowed per session
    const url = 'https://api.chucknorris.io/jokes/random'
    return (dispatch, getState) => {
        if (!getState().tooMany) {
            if (getState().jokeCount >= max) {
                // Runs synchronously
                dispatch({type: 'TOO_MANY'})
                dispatch({type: 'SET_JOKE', payload: 'cutting you off'})
            }
            // Runs asynchronously
            // NOTE THAT A PROMISE IS BEING RETURNED HERE!
            else return fetch(url)
            .then( res => res.json())
            .then( res => {
                dispatch({type: 'INC_JOKE_COUNT'})
                dispatch({type: 'SET_JOKE', payload: res.value})
            })
        }
        else {
            // Runs synchronously
            dispatch({type: 'SET_JOKE', payload: "no more jokes"})
        }
    }
}

As I mentioned in the prior section, please note when a Promise is being returned from inside the function. Neglecting this inadvertently can lead to a world of pain, hence the ALL CAPS!

Final Step - Pass those tests

Time to type npm test and look at all that glorious green!

Additional Resources:

There's a lot more to testing React and Redux, and I enthusiastically recommend checking out Bonnie Schulkin's thorough Udemy course on the topic:

To build your own Chuck Norris adjacent application, check out:
ChuckNorris.io

API Docs for:
React
Redux
Redux-Thunk
Jest
fetch-mock

Finally, I realize this is a pretty dense read, so remember...

Generating Dynamic Game Links with JWTs

edensongjbs — Tue, 18 Aug 2020 16:49:19 +0000

A few days ago, I set out with a coding partner to build a multiplayer game with React. The game will essentially be a digital version of Shobu, the popular and simple strategy board game. Central to the concept of our web app, a player can visit our site, generate a new game and send a link for the newly generated game to a friend. The friends could then play as opponents, each with a separate view of the game (and able to move only their own pieces). They could leave in the middle of a game, close their browsers, and reopen their game links from another device/browser and still have their game progress reflected.

The unique game links felt like a better solution for the app than requiring players to log in. No player information (other than a first name or alias if the user opted to type one in rather than defaulting to "Player 1" or "Player 2") would be stored in the database, and the backend model relationships provided for the player model belonging to the game model. Thus, once the game was over and deleted from the database, so too would be the players. In essence, each new game that a user would start would create an entirely new player instance, with a new unique game link.

I'd done work on previous projects with a Rails backend and handled authentication with a pretty standard password encryption approach. Now, I wanted to use some of those same tools, but try something new in the process that felt a little more appropriate for this type of project. So, how to achieve this?

Step # 1 Setting up the Rails Backend

We're using Rails as our backend API for this project, so I first needed to properly set up my API end points in my routes.rb file and generate a controller that could make use of the parameters I would be feeding in (namely, the dynamic portion of the game urls we'd ultimately be generating).

# in ./config/routes.rb
Rails.application.routes.draw do
  get '/players' => "players#index"
end

Rather than relying on typical RESTful routing conventions and use the #show route by including the player id in the URL (ie) http://domain-name.com/players/1), I decided to use JSON web tokens (JWTs) to send an encoded version of the unique player id to the rails back end. It seemed like a nice and easy way to encode the information I wanted to send and solve a couple of basic issues in the process:

Prevent players from accessing a game link other than their own (either accidentally or maliciously). If we stuck with accessing the API endpoint via the player id (which are assigned by the database sequentially), a user could easily guess at other player's URLs and sign into their game link, or even arrive at somebody else's URL by mistyping or omitting part of their URL. Using the JWT in the URL instead of an unencoded id makes it very unlikely that a user would wind up at a game that wasn't their own. Because of the way that JWTs work (utilizing a signature at the end to validate the data, and a secret key stored on the backend), it makes it exceedingly difficult to stumble upon another valid URL by chance.
Ensure that the game link is unique. There are certainly plenty of other methods to generate links, but this was the easiest way that I could think of to generate a link that was certain to be unique to the player in addition to being nearly impossible to guess. If we instead relied upon a concatenation of random words or random characters, we would either need to be comfortable with the (extremely unlikely) chance that two players would be assigned the same link, or take the extra steps to ensure that a collision never occurred (ie) potentially scanning through an entire database of used URLS each time a new link was created. As truly unlikely as a collision would be, the larger our user base, the more likely it becomes and the more unwieldy a possible used URL lookup table would be. I have actually run into colliding URLS on services like Surge.sh, so it's definitely NOT unthinkable.

Below is my code for encoding and decoding the JWT. The unique JWT "url" is assigned when a new player is created (as shown in player.rb, and that player can be easily retrieved from the database when the frontend sends that JWT back (as demonstrated in players_controller.rb). Please note that you will first need to include gem "jwt" in your Gemfile and run bundle install in the terminal.

# in ./app/models/player.rb
class Player < ApplicationRecord
    belongs_to :game
    after_create :generate_url

    def generate_url
        self.update_attributes(url: JWT.encode(self.id.to_s, "some_secret_string"))
    end
end

# in ./app/controllers/players_controller.rb
class PlayersController < ApplicationController
    def index
        player_id = JWT.decode(params[:jwt], "some_secret_string")[0].to_i
        player = Player.find(player_id).game
        render json: player.game
    end
end

Step # 2 Setting up Client Side Routing in React

After we get our backend successfully creating and processing the JWT as parameters in a GET request (I'd highly recommend a tool like Postman for testing the API), we can move on to our frontend. Since we built our game as a single page application in React, I'm going to demonstrate how to do this with client side routing via React-Router.

Since we handle a lot of the API calls for the game in our top App level, it seemed the path of least resistance was to define our client side routes one level higher, in index.js. We weren't envisioning multiple different looking pages in our app; just one basic page that presents slightly differently depending on whether or not there is an active game. Our routing is handling 4 basic scenarios:

1) Basic route ('/') - This route will render the page with a blank game board, and render a "Play a New Game" button. Once the button is clicked, we'll redirect to the primary player's game link. This route will cause our App component to render without any props and thus will not trigger initial API fetch request.

2) Valid game in progress in progress ('/gameinplay/some-indecipherable-jwt-that-decodes-to-a-valid-player-id') - This route will render the page with the current board of an ongoing game. Our router will render our App element and pass in the jwt as props. Because the jwt is present in the props, our App component will know to fetch the game details from the backend API discussed in the previous section. The view will be slightly different depending on which of the two game's players the link belongs to.

3) Invalid game link ('/gameinplay/any-other-string-that-is-not-a-jwt-that-decodes-to-a-valid-player-id') - This will be handled by our client-side router in the same exact manner as the valid link discussed in the previous scenario, however, the fetch request will return an error (since the jwt will not evaluate to a valid player id). We built some error handling to redirect the user to the root directory.

4) Any other invalid URL ('/any-other-string') - At the time of writing this blog entry, I haven't yet accounted for this scenario. However, I intend this to redirect to the root directory ('/') where the user can create a new game.

Note: You'll first need to run npm install react-router-dom in the terminal.

// in ./index.js
import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
import { BrowserRouter as Router, Route } from 'react-router-dom'

ReactDOM.render(
  <React.StrictMode>
    <Router>
        <div>
          // scenario #1, renders App with no props
          <Route exact path="/" render={() => <App />}/>
          // scenario #2 and #3, renders App and passes in the jwt as props
          <Route path="/gameinplay/:jwt" render={(routerProps) => <App jwt={routerProps.match.params.jwt}/>}/>
        </div>
      </Router>
  </React.StrictMode>,
  document.getElementById('root')
);

// in ./App.js
import React from 'react';

const playersURL = "http://localhost:3000/players"

class App extends React.Component {

fetchOngoingGame = () => {
    fetch(`${playersURL}?jwt=${this.props.jwt}`)
    .then(resp => {
      if (resp.ok) { 
        return resp.json()
      }
      else {throw new Error('Not a valid game link')}
    })
    // handling scenario #2 by populating the currentGame in state
    .then(currentGame => {
       this.pieces = currentGame.pieces
       this.setState({ currentGame: currentGame.game })
    })
    // handling scenario #3 with a redirect
    .catch(() => {
      window.history.pushState({pathname: '/'}, "", '/')
    })
  }

  // our initial fetch runs when the App component first mounts if there are props present
  componentDidMount() {
    if (this.props.jwt)
      this.fetchOngoingGame()
    else {console.log("This will load a new game")}
  }

Conclusion

We now have both pieces (frontend and backend API) up and running and connected. This seems a relatively straightforward approach to user authentication when security and user data is not a concern, as in the case of our simple web game. This is the first time I've attempted this approach, so I'd be very interested to hear some feedback from others who have attempted similar things and see how they approached the same problem. Thanks for reading!

Building Ada's Rainbow Piano

edensongjbs — Tue, 14 Jul 2020 13:26:09 +0000

Some Background

Learning Javascript has been both gratifying and frustrating in equal measure. There's an immediacy to it that I've found a lot of fun: seeing my code in action and easily manipulated in the browser! And then there's a whole bunch of stuff that left me scratching my head when my code breaks down (async, promises, scoping, callbacks, argh!!)

Starting out, I wanted to mark my progress with a fun little project for my 3 year old daughter Ada (which I later went on to build into a more full featured web app Ada's Ear Training. We've been working together for a while on some basic music theory and ear training. Her main introduction to playing music has been through these color coded pat bells that she received as a Christmas gift from her great grandma:

I thought it would be useful to introduce the concept of the piano keyboard using the same color coding (mapping each note in the C major scale to a specific color). Thus, my inspiration for Ada's rainbow piano.

If you're curious, below is a step by step tutorial on how I built it. And if you'd like to see and/or try out the code yourself, here's a link to the repository on GitHub

Tone.js

At the sonic heart of this project is the pleasantly intuitive Tone.js interactive music framework. It's a really powerful tool with various tone generators, oscillators, effects, and built in sampler, but for this project I really just scratched the surface of its capabilities. I ended up just downloading the source code and including it right inside my project directory, opting to avoid the ES6 import statements that were suggested in the README.

It's very easy to set up a basic synthesizer instance and patch it to the computer's audio output. I initially played around with the basic monophonic option for my initial tests, but went with a 4 voice polyphonic version for the finished code, so we can play full chords etc.

var synth = new Tone.PolySynth(4, Tone.Synth, { oscillator : { type : "square" } }).toMaster();

I've subsequently spent some time experimenting with sounds and linking it up to some real piano samples, but I've always had a fondness for a good ol' square wave, so this seems like a good place to start.

The UI Layout

After I was comfortable playing sounds and triggering attacks and releases for specific notes, it was time to build the user interface. Honestly, the most challenging bit about this little project wasn't the JavaScript, but the CSS styling! I hadn't ever written a ton of CSS, and positioning elements had always seemed a mysterious art form. This project proved to be excellent practice! (Note: For later projects using the keyboard, I decided to work with Flexbox and CSS Grid instead)

I started with one large <div> for the full octave keybed, and created an inner <div> for each separate key. I created separate classes for 'white-keys' and 'black-keys' and each key got its own id corresponding to its note letter and octave (C3, C#3, D3...B3, C4). This enabled me to make very specific CSS selections for intended coloring scheme, and provided an easy mechanism to send the corresponding note name of my mousedown events in order to play the intended note. It was important to specify that my key <div>'s were given CSS styling values of display: inline-block; so that they would display within the keybed <div> and not jump to the next line. The 'black-keys' class required need some additional styling: position: absolute; so they could overlap the 'white-keys' and be placed explicitly (make sure to specify a position attribute value for the enclosing keybed <div> as well or the black keys won't move with the rest of the keyboard!). It was a bit painstaking, but I specified a top and left value for each separate black key <div>.

Wiring it all up

Now that I knew enough of my way around Tone.js and had a fun and colorful UI I was basically pleased with, it was time to write my JS functions to get this thing working! I wanted to give the "user" (my 3yo) a couple options for trigger pitches: clicking on the trackpad and pressing keys on the keyboard. I wanted each to track both the mousedown/keydown events as well as the mouseup/keyup events for specifying the note attack and release.

I started by adding the event listeners for the "click" to each separate key <div>:

for (const note of allNotes) { note.addEventListener('mousedown', () => { playNote(event.target.id) }) note.addEventListener('mouseup', () => { releaseNote(event.target.id) }) }

As mentioned above, each event sends the id of the clicked <div> element as a string parameter to the play/release functions.

I had to approach the keyup/keydown events slightly differently. I attached the event listener to the document DOM element and sent parameters to the play/release functions by way of a 'keyBindings' object that I created in order to avoid an undoubtedly ugly if/else/switch/case statement. The keys of the 'keyBindings' object are the characters of keys pressed and the values are the note names (matching the id of the 'key' <div>'s).

const keyBindings = { "a": "C3", "s": "D3", "d": "E3", "f": "F3", "g": "G3", "h": "A3", "j": "B3", "k": "C4", "w": "C#3", "e": "D#3", "t": "F#3", "y": "G#3", "u": "A#3" }

Final Touches

To provide a little visual interactivity to the rainbow piano, I decided to add some additional CSS styling to indicate when a note was currently playing. In this case, it was just a matter of adding an additional ("playing) class to the key <div> when the note attack is triggered and removing it when the release was triggered. Here are the updated playNote and releaseNote functions:

playNote = (note) => { synth.triggerAttack(note) const noteDiv = document.querySelector(#${note.replace("#", '\#')}`)
noteDiv.classList.add('playing')
}

releaseNote = (note) => {
synth.triggerRelease(note);
const noteDiv = document.querySelector(#${note.replace("#", '\\#')})
noteDiv.classList.remove('playing')
}`

The additional styling subtly reduces the note's opacity to provide a highlighting effect when the note is played:

div.playing { opacity: 0.7; }

And that's basically it!

In Closing

The rainbow piano was definitely a fun first mini JavaScript project! Ada was pretty enthusiastic as well. At I mentioned earlier, I did go on to build this into a a more fully featured music theory and ear training application. I'm well aware that this is not the only "Build a JS Piano" tutorial out there, so I'll probably go back and read some of the others and see how the approaches differ. I'm somebody who enjoys the process of figuring things out for myself and struggling through the mistakes along the way, so I was hesitant to read any of those beforehand. Anyway, happy piano building!

The Full Ear Training App
Video Demo For Ear Training App

Remember the environment!

edensongjbs — Tue, 23 Jun 2020 13:49:42 +0000

How ignoring my Rails environment got me into trouble

A couple days into learning Rails, I was coming off after a frustrating week of managing tedious Sinatra syntax errors, malfunctioning gems, and inexplicably failing Capybara tests. I kept hearing that “Rails is magic” and I was very ready to embrace some of that “magic” and offload a lot of the manual and human error prone repetition of Sinatra to a framework that does much of the heavy lifting. However, my first experience with Rails left me wanting to pull out my beard. In fairness to Rails, and as with most coding issues, this was an easily resolved problem if only I had known where to look.

The assignment: I was given a partially built basic web application to track student enrollment, and I was tasked with building out some additional functionality and make a simple change to a table in the database, namely whether the student was currently "active" or "inactive." I needed to add an additional table column, and I decided to do this by modifying the original CreateStudents migration to create a new, larger table from scratch, rather than creating a new migration just to create the additional column in the existing table.

So I rolled back and re-migrated with the original migration file that I just modified. After seeding my data, I verified that the new attribute was showing up in my newly created student instances.

=> #<Student id: 1, first_name: "Daenerys", last_name: "Targaryen", active: false, created_at: "2020-06-20 21:42:23", updated_at: "2020-06-20 21:42:23">

...and my table schema...

ActiveRecord::Schema.define(version: 1) do create_table "students", force: :cascade do |t| t.string "first_name" t.string "last_name" t.boolean "active", default: false t.datetime "created_at", null: false t.datetime "updated_at", null: false end end

All good! However, when I went to run my capybara tests, I was failing. Capybara was claiming that the attribute and associated methods didn’t exist!!

 ActionView::Template::Error:
   undefined method 'active' for #<Student:0x00007fac65ac9108>

I had literally just confirmed that it was there! I used byebug to peer inside the test run, and to my astonishment, saw that the attribute was indeed missing from the Student instance in question...

<Student id: 1, first_name: "Daenerys", last_name: "Targaryen", created_at: "2020-06-21 00:08:53", updated_at: "2020-06-21 00:08:53">

So, what was happening? The answer lies in the way that Rails handles environments.

I felt fairly comfortable with the concept of an environment in Ruby and understood the utility of the environment.rb to help centralize all our require statements and wire up all our far flung classes and methods. I had seen references to the existence of different environments (test, development, production) within ActiveRecord and Rails, but hadn’t yet spent the time to truly understand what they are and how they work. I knew that the Capybara tests were somehow using a different set of data than I was, but hadn’t really thought through the mechanics of how this was accomplished.

It turns out that the tests operate in the capybara “test” environment and my own data seeding, testing, and manipulation exist in the “development" environment. So, while I had modified my table in the “development” environment (rails treats this as default, if RAILS_ENV is not explicitly defined in the shell command), I had not properly rolled back and rerun the updated migration in the “test” environment. Thus, the capybara tests were still using the old table schema.

ActiveRecord/Rails further complicates matters since there is only a single schema.rb for the project and it does not account for discrepancies between the databases for different environments, nor does it reflect the state of one environment in particular, but instead seems to update to reflect the most recent migration task.

So, what is the purpose of the environment? From what I've learned thus far, Rails tries to preempt our needs and define some default behaviors that would likely be useful in each stage of the project development cycle. One such aspect of this behavior is to separate the databases for each of the stages. The "test" database is populated according to the specific tests and purged between test runs, for instance.

There are far more environment implications beyond managing the project’s database, and each environment includes is own set of configuration settings and gems. Each of the predefined environments in Rails (you can define your own as well) is optimized for its set purpose. The "production" environment is optimized for server speed while the "development" environment is optimized for easy modification, allowing us to make changes to our app files without having to stop and restart our server. Pretty useful!

Some developers have shared their own approaches to using and creating some custom Rails environments, and I'll link to some of those below. Additionally, Rails Guides provides a ton of information when it comes to configuring components within each environment. In fact, Rails provides some very useful info about the purpose of each environment and component configuration as comments within the environment files themselves (inside the config/environments directory).

While I’m just at the beginning of my Rails journey and certainly no expert on the topic, I do want to urge you to take a minute to understand the implications of environments on your databases, and not make the same mistake that I did. It was a real headscratcher/beard-puller and I’m hoping I can help save a fellow Rails newcomer some precious debugging time on their next project.

The takeaway: if you’re running tests in the “test” environment and have made any changes to your database, remember to add a RAILS_ENV=”test” to your rake/rails db: commands!

Resources
Ruby on Rails Guides: Configuring Rails Applications
Beyond the default Rails environments - Signal v Noise
Use of Ruby on Rails environments - Enrico Teotti
Creating Staging and other environments in Rails - Josef Strzibny