Building Up or Breaking Down: Creating States-n-Plates

In piecing together States-n-Plates, I wanted to learn more about React, a web application library created by Facebook. In the process, I found myself finding parallels in how I go about learning anything.

Before I describe the details, I’ll give a (hopefully brief) description of what React does.

An HTML page normally consists of HTML tags that tell the browser what to display, with other rules that also describe how the HTML should look. A page created through React reframes that page as a series of components that each serve a different function. The image components need to have the ability to be dragged onto the targets. The targets need to be able to accept a dragged image, and need to be able to indicate whether the image dragged onto the target corresponds with the correct plate. The scoreboard needs to know how many states have been correctly matched at any given time. The components also have the ability to respond when a user clicks, types, or drags other components into them.

In a well designed React application, each component uses information from the component that contains it in order to behave (or, um, react) as the application is used. Building the pathways for how this information flows from one component into another is deliberately designed so that each component can act independently from another.

When I first started working on creating States and Plates, I started with a fully formed webpage that looked much like the final product above. I followed the React documents that then suggested breaking the page down into components, one by one. I did this without really understanding in detail what I was doing, but was able to get the components to each have the appearance of the original web page, which felt like real progress. Eventually, my progress was halted when I reached the limits of what I understood. I needed help.

It was at this point when I picked up a book on React and started working through the basics. I began to understand better what the guiding philosophies of React were – the design decisions, the behaviors that one component had in response to another, and how to think through an application the React way. This was where it was helpful to read the perspectives of some people much more experienced then me – I understood the vocabulary they used and could make the connections I needed to make progress.

With some of the basics figured out, I rethought the application from scratch. Rather than starting with the webpage as a whole, I started creating components and making sure each one worked as expected before moving on.

By the end, I felt comfortable thinking about my application both from a bird’s eye view and on an individual component level. I needed to have the experience of breaking the idea down into individual pieces and seeing how they interacted with each other to produce the whole. I needed to take time seeing what rules guided the function of one component in order to understand the whole. If I had started by reading the documentation as my step one, I would not have had the context that the big picture view of the application yielded for when I actually did so in my learning. Both views were important, and neither view was sufficient on its own to lead to full understanding or transfer.

We need to give our students opportunities to have both views of the content we teach. Insisting that student mastery of the basics is a necessary gatekeeper to higher levels of thought misses opportunities to understand the context of that basic knowledge. Student exploration of concepts through Desmos or Geogebra or problem solving is a great way to engage with the standards of mathematical practice, but without discussion, review of underlying concepts, or (gasp!) direct instruction where needed, opportunities for growth might be limited.

Let’s make sure, as a team, that we are attacking this problem from both ends.