All posts by Sean Dolinar

How to Create a Blank .chr file for NES Homebrew

If you find yourself needing to make a blank .chr file for an NES homebrew game, here is a quick shell script to create a blank 8 KB .chr file.

#! /bin/bash
for ((a=0; a <= 8191 ; a++))
do
    printf "\x00" >> file_name.chr
done

It just writes out 8,192 bytes of zeros into a binary file. You should then be able to open this up in a .chr editor.

Using React Context Hooks For Data-Heavy Apps

I build a lot of mini data-heavy React apps, so I wanted to share my basic architecture. The apps I work on typically have a small number of different REST API calls usually with several parameters that can be changed to query the data set. This might not work for everyone, and I’m not sure how well this scales to bigger applications, but I like how this works for my needs.

With the addition of hooks, functional components in React became a lot easier to write. This is my preferred method of creating React apps at the moment, because it simplifies the code a lot [particularly with the this.handler = this.handler.bind(this) code mess in the constructor] Coming from React Classes, I had to change my basic architecture a little bit, but I’m happy with what I arrived at.

What I’m going to make here is a quick app that has

  • One data API call
  • One Control component
  • One Presentation component
  • The app will display the current time when a time zone button is pressed.

React Context Hooks Time App


GitHub

Here’s an overview of component tree of this architecture.

  • The App just wraps and organizes the app. There can be more there, but we are keeping it simple here.
  • The Controls component will have two choices for time zone. Clicking a different button will change the parameter and make another REST API call.
  • The Presentation component for me typically contains a data grid or other items which present the return from the API. Here it’s just text with data from our time API.
  • The DataContainer component is where this gets interesting. I’m housing all the API fetching, state and control handlers in this component, so we don’t burden the App component with this.

App.js

const App = () => 
        
        
    

This is straight-forward and clean.

Controls.js

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

import {ContextItem} from '@src/context';

const Controls = () => {

    const {appParam, methods} = useContext(ContextItem);

    return 
}

The Controls component has two buttons that fire off a method on a click and use our app’s parameters to provide control feedback. This line: const {appParam, methods} = useContext(ContextItem); is the context hook and it’s the key to making this work. I like that this is almost the same bringing props into your class component.

I’m also sending methods along in the context so that we can manipulate the app’s state when the users press the button.

It should be noted that the import statements are necessary for these types of components particularly when we what to use a context. They are also omitted in subsequent component snippets for brevity.

Presenation.js

const Presentation = () => {
    const {data} = useContext(ContextItem);

    return 
The current time for {data.timezone} is: {data.datetime.slice(0, 16)}
}

Same idea here, as the Controls component. We are using the data from the app’s state which we retrieve through the context API to populate the text with some information.

Data Container

const DataContainer = ({children}) => {

    const [data, setData] = useState({datetime: ''});
    const [appParam, setAppParam] = useState({tz: 'UTC'});

   
    // HANDLES DATA
    const getData = () => {
        fetch(`https://worldtimeapi.org/api/timezone/${appParam.tz}`).then(res => res.json().then(json => setData(json))) 
    }

    useEffect(() => {
        getData(); // This hooks gets the data once after the component mounts
    }, [appParam.tz]) // this will run again when the tz prop changes

    // HANDLES EVENTS / STATE MANIPULATION
    const handleAppParamChange = (obj) => {

        const newAppParam = Object.assign({}, appParam, obj);

        setAppParam(newAppParam);
    }


    return 
        {children}
    
}

Here’s the fun part. I use the Data Container as a wrapper, so that the App component has the component layout of the application in it. This gets useful with larger apps, when you want to see multiple data tables or control components.

This component has four parts:

  • The useState() hooks
  • The REST API data fetching
  • The event handler methods
  • The Provider and render return

The useState() hooks are how you define your state structure. This can get more complex, but the nice things about hooks is that you can have different state variables for each important element. In this I’ve broken it up into two parts: data and parameters.

The REST API data fetching handles the promises and fetch calls along with when to run it. Previously in React classes, you would have used the componetDidMount() life cycle method, but with React Hooks we use the the useEffect() hook. The array used as the second parameter in useEffect() determines when that effect will fire again. I put the time zone parameter in there so that it will fire whenever there’s a new time zone to retrieve a new time. [This is a lot cleaner than before.]

The event handler is pretty straight forward. I take the obj from the controls to update the current appParam state value. Then update that state value. Once that updates the useEffect() sees the value for timezone has changed and it fires again.

The last part of the component is the return part. This creates the Provider, puts the state and methods that manipulate that state into the context. The component is made into a wrapper by include the children props in the middle of the Provider.

Conclusion and Benefits

Now I can’t speak for any performance gains or hinderance, but from a code readability stand point I find this approach:

  • Organizes API calls
  • Allows you make subsequent API calls based on parts of state that changes. Eliminating awkward asynchronous issues involved with updating state and using that state to make an updated API call.
  • Prevents props drilling by allowing you to access any part of your context as easily as you would props.
  • Provides a clean organization of components in your app. The Controls and Presentation component don’t have repetitive and messy props to worry about.

Automatically Build GatsbyJS Site When Publishing WordPress Post

With a headless WordPress site, you need a way to communicate with the front end when there is a new post. With a AJAX-only site, the API update should be sufficient, but with a Gatsby or other static site, the site has to rebuild with each update. I’ve created a quick plug-in for WordPress on my GitHub. It can also be incorporated into the functions.php of your WordPress

So how to trigger the rebuild?

Build Hook

Netlify makes that easy with build hooks. Build hooks can be created in the site settings menu under Build & Deploy >> Continuous Deployment.

What build hook is just a URL that you sent a POST request to in order to trigger a rebuild. And that can be easily done with JavaScript specifically with jQuery and it’s AJAX methods.

Sending the POST Request

The wp-admin panel runs jQuery so we’ll use it to send the POST request. Below is the JavaScript code that sends the POST request.

jQuery.ajax({
        type: "POST",
        url: 'https://api.netlify.com/build_hooks/[site specific code]', 
        success: function(d) { 
            console.log(d)
    }
})

Trigger From WordPress

We have code to fire off the POST request, but we also have to attach it to an action. There are a few different ways to do this, the simplest way I found was to attach the POST request to the action of pushing the publish button or the update button. We can do that by putting an event listener on those buttons. The code below does two additional things to the initial AJAX snippet of code.

  • It attaches the POST request to the #publish and #original_publish buttons, which are publish and updates buttons.
  • It also limits the event listener to only the post.php page.
jQuery(document).ready(function() {

    //enables only on a normal post page
    if (adminpage == 'post-php') {

        //event handler for clicking the link button
        jQuery('#publish, #original_publish').on('click', function(e) {

            jQuery.ajax({
                type: "POST",
                url: 'https://api.netlify.com/build_hooks/[site specific code]', 
                success: function(d) { 
                    console.log(d)
                }
            })
        })
    }
})

Include the JavaScript in Your WordPress CMS

The final step is to include this JavaScript into the JavaScript files that WordPress runs. We can do that with the admin_enqueue_scripts WordPress action hook.

function wordpress_netlify_enqueue($hook) {
    if ( 'post.php' != $hook && 'post-new.php' != $hook ) { 
        return;
    }

    wp_enqueue_script( 'wordpress-netlify-hook', plugin_dir_url( __FILE__ ) . '/wordpress-netlify-hook.js' );

}

//enques the scripts from wordpress_netlify_enqueue
add_action( 'admin_enqueue_scripts', 'wordpress_netlify_enqueue' );

This takes the JavaScript file and attaches to the post.php and post-new.php pages, so that the script runs when the page loads.

New Blog Front End Using GatsbyJS

If you visit this site often, you might have noticed a layout change this week. I rebuilt the front end of my blog in ReactJS and GatsbyJS. I’ve been wanting to rebuild the front end of the site for a while now, and I didn’t want to start a new project in PHP and try to shoe horn in ReactJS, which is my JavaScript front end library of choice. GatsbyJS was the solution I settled on. The blog now (as of writing this) consists of static files instead of rendering a PHP page every time. I’m going to write more about the entire process. Not all of it was smooth, but I really like the performance and product that this stack has provided so far.

To give you an overview of the tech stack.

  • WordPress is the CMS. I use the same WordPress install I had before, but I’m now using it only as a CMS. The REST API feeds the data into Gatsby.
  • GraphQL is the querying language that Gatsby uses to interface with the WordPress API. It’s pretty fresh at the moment. I found it easy to pick up in a basic, functioning sense. I have yet to set it up or do difficult queries.
  • ReactJS is used to create pages and components for the site. I have a lot to say about React in general, but I’ll save that for other topics. To me, using React in this context of generating static pages made it look like React is an evolved form of HTML.
  • GatsbyJS does A LOT. In short it takes your data with React pages, templates, and components then generates HTML/CSS/JS files for upload to a hosting platform. It also creates service workers and creates “blazing fast” sites. The speed bump alone is worth considering for a WordPress site. Not to mention it gets you out of PHP world.

There are a few downsides, since it’s a static site generator, it takes several minutes for a new build of this site, which is ~80 pages. I do not frequently update the blog, so this isn’t an issue here.

You could also build client-side apps and have dynamic data updated via AJAX calls, so the “static” part of the static site isn’t quite that rigid. You just can’t have a server render pages.

React Context API: Multiple Consumer and Providers

With React’s Context API you are able to use multiple Providers and Consumers using different context instances. This could be useful if you want to separate different data models into distinct parts of your app. For example, you could have a data context and a table context. One context instance could be used to control what data your REST API is sending back, while another instance controls your sorting, paging, etc.

Continuing the extremely simple light bulb example, I’ve decided to build multiple rooms (a living room and a hallway) with some switch wall plates and a light in each room. This should be a familiar setup to anyone who has a three-way switch in their hallway, so you can turn the hallway light off at either end of it. In order to make this, we will create:

  • “Circuits” (context instances) for the living room and the hallway
  • Wall plate components for each room to house light switch components
  • A three-way switch for the hallway light
  • A normal switch for the living room light
  • Light bulbs for each room

Putting that together we get the mini-app below:

The full code is available on my GitHub, but let’s start with the core App component:

app.js 📄
class App extends Component {
  constructor(props){
    super(props)
    this.state = {on1: false, on2: false}
  }

  //Room (living room) and Hallway are the two different rooms.
  render() {
    return (
      
this.setState({on1: !this.state.on1 }) } }> this.setState({on2: !this.state.on2 }) } }>
living room
hallway
); } }

There is a lot of component composition here. We have a WallPlate component for each room along with a component for the room itself which houses the light bulb. We have the two providers wrapping the both rooms with the values defined in terms of the App’s state and a method that can set that state. For this example we are using numbered circuits:

Circuits (Context instances)

  • LightCircuit1 — (Living) Room
  • LightCircuit2 — Hallway

The context instances also correspond to a specific variable in the main app components’s state; once again either 1 or 2. In the interest of being straight forward, each context instance have the different states hardcoded into the Provider’s value. If you were using them to control data and the table view separately the Provider’s initial value object should look demonstrably different from each other, but since this is a just a demonstration, they look similar.

The component of most interest is the WallPlateLivingRoom component. It’s the only component which has multiple consumers. [The rest of the components resemble the last few React Context API examples.]

WallPlateLivingRoom.jsx 📄
class WallPlateLivingRoom extends Component {
    constructor(props){
        super(props)
        this.state = {up: false}
      }
    render() {
      return 
{ ({flipSwitch}) => } { ({flipSwitch}) => }
} }

I think the Consumer use is pretty straight forward. You need to first use the correct consumer for what you want to do, then pass the context to your child components as you would with just one component. The React docs show nested Consumer components, but they don’t need to be.

This is a simple example, so using Context API like this is overkill, but you can see how you are able to use different context instances within your app. If you have questions about the basics of Context API or are curious about some of the building blocks of code used in this example check out the previous posts on this topic: A Way Too Simple Context API Example, Context API: Three Way Light Switch.

React Context API: Three Way Light Switch

In the Way Too Simple Context API example, we made a simple light switch. This post will show why flux, the single source of truth, and Context API are really useful.

The last post had just two components (not counting the App component): a light switch and light bulb. Here we are going to add a second light switch making this circuit mimic the three-way switch common in many homes.

In this system we want the following to happen:

  • flipping any switch will change the state of the light
  • the “physical” direction of the switch shouldn’t matter

This is meant to represent a switch in real life, and physical switches don’t throw themselves in response to a change in the system. On a web app, you’d most likely want the component’s feedback to change to reflect the state of the app. If you are curious about how three-way switches work in electrical circuits, it’s quite interesting. Unlike the electric circuit, our mini React app has a single source of truth and by manipulating that we can affect the whole system.

Luckily, because of the way we designed the original Context API light switch app, adding another switch is easy enough as putting a second light switch in the App.js file in the three-way-switch branch of the Context API example project.

app.js 📄
import LightCircuit from './context/context'

class App extends Component {
  constructor(props){
    super(props)
    this.state = {on: false}
  }

  render() {
    return (
       this.setState({on: !this.state.on })
        } }>
        
); } } export default App;

We also added a few aesthetic things: the three-way class to remove the “on” / “off” label and another spacer, but to make this work, all that was added was just another LightSwitch component!

The magic is in the flipSwitch: () => this.setState({on: !this.state.on }) function in the Provider that gets passed to the LightSwitch component and run when someone clicks on the component. The flipSwitch function also looks at the App component’s state for the on property, negates it, and then sets it as the negated value creating a toggling effect.

Once again, since this is a simple example, we could accomplish this by lifting up the state and sending it back down with props, but with Context API it doesn’t need that direct chain. LightSwitch can place it in other components (like a Room, LightPlate, etc.) as long as they are children of the Provider.

A Way Too Simple React Context API Example

React’s Context API is convenient built-in state management for React Projects. It has it’s advantages and disadvantages over a library like Redux for sending props and changing the app’s state. I’m going to focus on the advantages of using Context API and getting an overly simple example to work.

The example in this post only has two levels of components, so it is actually advised against by the React documents. If you were actually making an app with this few of components it would be easier just to pass props and lift up state. But let’s figure out how Context API works! Below is a mini React Context API app that is a light bulb and a light switch.

I’m going to assume a few things:

  • a working knowledge of React.
  • familiarity with the single source of truth behind the Flux model in React
  • familiarity with ES6 JavaScript syntax

Also, the full code for the project is at https://github.com/seandolinar/context-api-example, but the code excerpts in the post are only the relevant parts (I left out the import statements, etc.). I made it with create-react-app, which is a pretty good quick start boilerplate for playing around with React without a lot of setup time.

Alright! There are really just three normal React components:

  1. the App
  2. the LightBulb
  3. the LightSwitch

The app’s global state only has the lightbulb on/off, which affects only the display of the LightBulb. And that state can be changed by only the LightSwitch. Overly simple; let’s go through some code!

context.jsx 📄
export default React.createContext()

Alright, this is too simple. We create a context that can be imported into the different the components.

app.js 📄
import LightCircuit from './context/context'

class App extends Component {
  constructor(props){
    super(props)
    this.state = {on: false}
  }

  render() {
    return (
       this.setState({on: !this.state.on })
        } }>
        
); } }

This object is the heart of the app, so let’s start here. We create a state in the App’s constructor, initially setting the state.on = false. The new part is the LightCircuit.Provider Context API component. It wraps the what would have been the root app component. The value attribute of the Provider is the default/starting value. There are two items in the default context:

  • the App’s state [state]
  • a function for changing the App’s state [flipSwitch()]

This will be passed to any Consumer components like in the LightBulb component.

LightBulb.jsx 📄
import LightCircuit from './context/context'

class LightBulb extends Component {
    render() {
      return 
                {
                    ({state}) => 
}
} }

This component is just a Context Consumer component, and a div that uses the context’s state. The ({state}) => part of the arrow function destructs the context and only uses the state, which is then used to change the className which controls CSS to show the light bulb is lit or dark. The div that’s inside the consumer component could be any component, composition of components, or even JavaScript.

The annoying thing about Context API is having to pass the context through the arrow function. It creates some JavaScript structure I’m not crazy about since it limits what you can do with the context in that component without additional code.

LightSwitch.jsx 📄
import LightCircuit from './context/context'

class LightSwitch extends Component {
    constructor(props){
        super(props)
        this.state = {up: false}
      }
    render() {
      return 
                {
                    ({flipSwitch}) => {
                        const handleClick = () => {
                            this.setState({up: !this.state.up})
                            flipSwitch()
                        }
                        return 
                    }
                }      
            
    }
}

The LightSwitch component does one important thing: it runs flipSwitch() from the context, which in turn changes the state in the top-level App component. We are destructuring the flipSwitch() from the context then putting that into a catch all handelClick() function to run when the button is clicked.

I did add one extra layer on complication, I create an up and down state internal to the switch. Since the circuit doesn’t affect the position of the physical switch in real life, so it shouldn’t here. That is why the extra handleClick() function was made and why the LightSwitch component has its own state.

Conclusion

Hopefully, walking through the simple example with Provider, Consumer and Context can help you get Context API working for your app. Again, this is too simple of a demo, and actually a bad example of how to use it. It works well if the light switch was buried within a hypothetical LightPlate, Wall, Room, and Circuit component. That way you wouldn’t have to lift up state through several layers of components.

My Dead Simple Redux Example

If you are here, I assume you are banging your head against the wall trying to figure out Redux for a React project. If you are looking for a quick start for a React project that has Redux already setup then this is a good boilerplate: http://mikechabot.github.io/react-boilerplate/.

But you are probably still a little confused on how the Redux part of that works…or at least I was. Even the demos on the official Redux site have a lot of complications to illustrate more features, so it takes a while to learn the skeleton structure of the library.

For my example. I’m going to assume a few things:

  • a working knowledge of React.
  • familiarity with the single source of truth behind the Flux model in React
  • a node.js / webpack build environment
  • familiarity with ES6 JavaScript syntax

The example is going to be an on/off switch and a “light bulb” that also has an on/off state. Here is the code and the deployed example. So there will be one action with two values. Dead. Simple. [If you need more complicated examples, please references some of the more involved tutorials. My example is only meant to show the relationship between the components and the parts of redux.]

I’m going to divide this tutorial into two parts: 1.) the Redux parts and 2.) the connection into React components.

Redux

Let’s first look at the three parts of Redux:

  • Store — keeps the single state of truth in its state and dispatches actions
  • Action — the thing that’s dispatched to a reducer
  • Reducer — a function that takes the previous state and the dispatched action and returns a new state

Here is the diagram I use to help me think about what’s happening.

The one thing I want to draw your attention to is the Dispatch() and action part. The action itself isn’t really doing anything. It’s just a JavaScript object. But the dispatch() method within the store is what actuates the entire process, not the action.

So let’s look at the example’s code.

Action

export default function flipSwith(value) {
    return {
      type: 'FLIP_SWITCH',
      value
    }
  }

There is nothing special going on here. We are not importing any dependencies. All this is is just a function that returns a JavaScript object like { type: 'FLIP_SWITCH', value: 'off'}. The type property is use by the reducer to determine what type of action is being dispatched. In our simple example the value with be either 'on' or 'off'.

Reducer

const lightSwitch = (state='off', action) => {
    if (action.type == 'FLIP_SWITCH') {
        state = action.value
    }
    return state
}

export default lightSwitch

Once again there are no dependancies here, so there is nothing special going on here either! The reducer is just a function that takes a state and action as parameters and then does something with those to create a new state. In our case we test the action’s type property to make sure it’s 'FLIP_SWITCH', and if that’s true we set the state to the action’s value. [Either 'on' or 'off'.]

The reducer will return a state to the store.

Store

import { createStore} from 'redux'
import reducer from './reducer'

const initialState = 'off'

export default createStore(
        reducer,
        initialState
    )

Alright now we have some fancy dependencies. We use the createStore() from the redux package to create our store. It takes the reducer and the initial state as parameters. Here I set the initial state to 'off' and import the reducer we just made. This is how the store is aware of the reducer.

State
A word about state. In our example we are using a string as the state. But this could be a JS object instead. Most other example will use a JS object as the state.

React

I don’t want to get into React components and all of that stuff. The two components I made for this example are pretty simple and use props and an event listener / handler. The details of the components don’t matter all too much. The interaction of Redux and React come from the connection and the mapping functions.

This the entire app.jsx code. I’ll go through the important parts and it’s not necessarily in order.

connect()

const ConnectedApp = connect(
    mapStateToProps,
    mapDispatchToProps
)(App)

For this App is a React component. What we are doing is connecting the dispatch and state from Redux to our App component. The mapStateToProps and mapDispatchToProps are both functions.

mapStateToProps

const mapStateToProps = (state) => {
    return {
      power: state
    }
  }

mapStateToProps takes the state from the store and passes into the connected component’s props. In this case we take the state which is a string and pass it into App‘s power prop. It returns a JavaScript object that it merges into the components props.

mapDispatchToProps

const mapDispatchToProps = (dispatch, ownProps) => {
    return {
        onChange: (value) => {
            dispatch(flipSwitch(value))
        }
    }
}

So we can get the state into the component but how to we actuate change in the store? With dispatch! So what we are doing here passing a function to the components props that runs a dispatch() method inside of it. Here we are passing the a function that takes the on/off value into a flipSwitch action which is dispatched to the reducer which then updates the store’s state, which because of the mapStateToProps function, updates the components power props.

Provider

ReactDOM.render(
                    
                
                , document.getElementById('light'))

This isn’t that interesting, but it’s necessary. To make it all work we place our ConnectedApp component inside a Provider component which deals with the store.

App

class App extends React.Component {

    render () {
        return 
} }

Let’s finally look at the App component. This is what’s connected to the store and the mapStateToProps and mapDispatchToProps functions. You can see the power props are passed to the LightBulb and LightSwitch components. These are just props since the mapStateToProps function is handling all of that for us.

Now the trickier part is taking the onChange function from mapDispatchToProps and placing it in the LightSwitch so it can run the function. This bit of code: onChange={this.props.onChange} accomplishes that. Which the LightSwitch changes it passes the on/off value into the function we defined in the mapDispatchToProps which dispatches our action (with the value) to the store.

Hopefully this tutorial helped you understand how the basic setup of Redux works. To make a more complicated app will require much more advance concepts you can find elsewhere on the internet such as combined reducers, async thunks, more complicated states, etc.