Comparing Data Flow to a Children’s Toy

Adam Schwartz
4 min readApr 20, 2021

Right now I’m a full-time student in software development. This often poses a problem because I get confused and overwhelmed easily. Like really really easily. My poor organizational habits and predilection for moving pictures and flashing lights certainly does not help. When doing any work at all, I instinctively grab my phone to refresh YouTube or my podcast app before the smart part of my brain says “hey no, we need to focus up, and having a video on right now won’t help that. Put it down,” Which would be nice if it wasn’t followed immediately by the fun part of my brain saying “You can work AND have stuff on in the background AND it’s probably time for a video game break!”

Basically, I have the attention span of a walnut. There’s a whole bunch of information going into these here ear and eye holes of mine and most of it is chaos. I spell this out mainly to illustrate that because of my myriad of poor habits, learning a new skill, like javascript, is a challenge for me and I assume many other scatterbrained individuals like myself. The concept I first try to get a grip on when I look at any code at all is data flow

A block of code to the untrained eye looks like a mishmash of nonsense. However, if you can focus on the idea that it’s all just data being passed around in the most ideal way possible, it becomes a lot easier to read. Basically, it turns you from a Neo into a Cypher in the below gif:

Unfortunately, I’m usually making a stunned Keanu face when I look at code.

One way to get just a teeny step closer to getting how to process code more effectively and quickly, I’ve learned, is by understanding how the data moves (or FLOWS) through it. You may not know what all the specifics are in a given chunk of code, but if you can gain a rudimentary understanding of what talks to what and passes data to where you can use context clues to figure out a great deal.

The best way I like to do this, obviously, is by thinking about a board game from the 1960s. That game is called Mouse Trap.

A visual representation of Javascript

Yes, Mouse Trap. The decades-old game about trapping cheese-addicted rodents is how I like to visualize literally every piece of code I look at. The trap itself is my code and the marble is the data being passed through. This may seem childish but I’ve found after staring at the same line for an hour yelling “BUT WHERE IS THE MARBLE”. Let’s look at an example:

const ourData = "marble"return `oh would you look at that! A shiny new ${ourData}!`

Super simple two lines here but it gets my point across. We’re working with a single variable that we declare on the first line and then it is interpolated in the second line. But it helps me, and possibly you (presumably. I can’t be sure. I don’t know your life) to think “without the marble starting down the first ramp in line one, line two would just be a useless static ramp with no marble fun.” Now let’s tackle something more complicated: Fetch requests! For purposes of example, let’s pretend I’m working on a json server that lists all my marbles:

"marbles": [{"id": 1,"name": "ol blue"},{"id": 2,"name": "Cat's eye"},{"id": 3,"name": "hungry hippo food"}
]

And let’s say we want to make a fetch request to dynamically list what’s in my marble server onto my personal website. Doing something super simple like this can quickly appear to spiral out of hand

function putMarbleOnShelf(marble){let marbleCollection = document.createElement("div")let oneOfMyMarbles = document.createElement("h2")}
oneOfMyMarbles.innerText = marbles.name
marbleCollection.append(oneOfMyMarbles)function populateMarbles(){fetch("https://localhost3000/marbles")
.then(res => res.json())
.then(function(marblesArray){
marbleCollection.innerHTML = " "marblesArray.forEach(function(marbleObject){putMarbleOnShelf(marbleObject)})})}populateMarbles()

That’s a lot more code! But if we break it down piece by piece and “follow the marbles”, we can figure out what’s going on. I like to start with the fetch request since that’s where our titular marbles begin their journey.

  1. the fetch request lives in a function called populateMarbles. When that function is invoked (which we’ll get to later) it will fetch the array of marble objects from our JSON server, and for each of them, run them through a function called putMarbleOnShelf.
  2. If we scroll up we see that that function on top of our code block! So putting the marble on the shelf takes in a marble object and makes an H2 element out of it and slaps it onto the dom in our Marble Collection div (which we also make within that function).
  3. Finally at the bottom of the code is the invocation for our initial function, starting the whole mousetrap.

Hooray! We did it! We followed our marbles through twists and turns, down ramps and tunnels, until they safely landed on the DOM. Obviously, code can get MUCH more complicated than this with many moving marbles in various directions. Sometimes they can even go UP ramps (it’s called inverse data flow and it’s a boy oh boy is it doozy when you first come across it). But as long as you think to yourself “where is my marble coming from, and where is it going,” you can make your life a whole lot easier.

--

--

Adam Schwartz

Full time software engineering student at Flatiron School