React, Data flow, and love of the Radio

Remember, when this was the internet?

Using React.js can be frustrating, especially if it’s your first framework. It’s not very forgiving and articulating your thoughts into working code can be a painful experience. No worries friend, let’s walk through a little thought experiment and make something cool. I’ll talk through each step and share my thoughts. Let’s make some radio buttons. They’re easy enough to make and can give us some insight as to how Data flows.

Let’s assume you’ve made a nice little Single Page Application about something you enjoy. It has an API or Database which is already being pulled in, passed down to different components. It’s styled nicely and renders properly, just one issue though. It needs a stream-line way to organize all those lovely objects you’ve rendered. You don’t want to do a Search Bar and you’ve ruled out the Drop Down (it reeks of 2010). Well, I hear radio buttons are all the rage these days! Let’s create this feature, but more importantly, let's use this to get a better understanding of React, Data Structure, and the way it flows.

Draw-Out the structure & make notes! Are you getting an assembly line vibe here?

Step 1: Scout & Draw-Out

I’ll be using VScode, but the principles I’ll point out here will still apply. You first want to look at your files. Check out where they live, understand how each one imports, exports and it’s relative location. Where’s the API being brought in? is it a file.json ?or maybe it’s just a file.js? How is the data be passed? Where does it end up? You need to answer these questions so you can orient yourself. Even though there are common patterns, you can end up making some costly mistakes. I find drawing out the structure is a major help. It gives you a quick insight into how the app works as a whole. You need to know which component does what, which file is responsible for which task? If you spend more time here, it will be less time debugging, trust me…

Step 2: Object of our desire

Now that we have our “lay of the land.” It’s time to get our hands dirty! We want our “Object” file to have the code for our Radio Button. Let’s think about this…

  • What’s a Radio button? …It’s basically an input tag set to “radio”, think a checkbox with a default option.
Think, think, think… why do bees make hunny ?

See how we did all that thinking before we even wrote a line of code. It’s like a car, you can drive around aimlessly, but your wasting gas. You won't know generally where your gonna go, roughly how many stops you’ll make, and roughly how long it will be. This allows you to be way more productive and efficient in writing code. So in short, if you’re gonna waste time, do it thinking it out, not typing as you go.

Step 3: Now we start coding

Radio Buttons what the user sees vs. what we as developers see!

Starting here in Object we are gonna code our way to the iterator of these objects we are trying to sort. Let’s create a form & input tag inside of it. Depending on how many options you want, but let’s go with 3. We want to give it a type, that’s set to radio and a value set to how we will organize this information. Next, let’s wrap each input field with label tags. In these tags, you can label your buttons. Remember this code has stuff the User can see! So take a minute to try and organize it to your liking, it has to satisfy your requirements after all.

Notice inside the onClick, we aren’t invoking the function, just referencing it !

Now that we are happy with how this lays out on the page. Let’s create an onClick to listen to the option being chosen. We want to create a reference of function inside the onClick, NOT invoke it. Next, we will create the actual function inside our class and above the render function. We also should make a state to act as “front-end memory storage”, will use it to hold on to the value of the button that’s clicked. It also re-renders state when you use “this.setState”, keep that in mind when reading error-messages and debugging in general. State has a few handy uses and is a powerful tool to use once you get comfortable with it. You will see how we can pass information up and down a file tree using state. Think about a bucket brigade, passing water, and the bucket they use! In this case, our state will act like that bucket, and our information is going to be the water.

Bucket Brigade, Blue people: our class /functions, buckets: state, water: information we need!

Notice how we used fat arrow notation here…

function name = (place argument here) => {

… stuff inside the function…


it’s to help bind our data to the function. We also passed it an event, which is the button we clicked on. In that, we have what we need, so grab the value off the target of that event. This is what we are after, now we save that info in our state, saving it under searchType.

Left: This is our handler we are referencing ! Right: Our state

Step 4: The containers, elevators, & iterators

How do we get that info in Object up to our container? Well, that’s where props come into play. props allow us to send up data and also grab data through the use of props + a function. Understanding this is key to passing info up and down your file tree. Remember the following…

Sending down data: you gotta build the elevator first, then send stuff up!

  1. create a function where you’d like the information to end up.

Wow, that’s a lot to understand. It’s the cost you pay upfront, I’m afraid but it’s peanuts compared to what you can do after you’ve mastered it. Search Bars, Drop Downs, passing data from your API all depend on you understanding this and the use of state. It’s bedrock, so take your time and let it sink in!

elevator is our function we are sending up info with, notice it takes an argument! FYI: We want cause it’s faster! The option of using this.state.searchType is that its asynchronous code, this doesn’t make it the best option :(

Meanwhile in our Container…🦇 🦸‍♂️🦇 🦸‍♀️ 🦇

Let’s create an elevator, same syntax as clickHandler. This time it takes an argument of what it’s carrying. Since it’s just a label we are slapping on this data let’s call it “buttonInfo” in camel casing, it’s for easy reference. In this function, we’ll set the state to this “buttonInfo” object in searchType.

See how this is starting to come together?

Step 5: Refactoring our Iterator Function for the User

See how our iterator function is invoked in our render(), this means we are in the right place. We want our users to change what is being iterated based on their button click!

Remember how we thought about this earlier in the blog. We know we are in the right place because we want to have the user’s decision affect the way they see organized objects/information. Let’s target our iterator function, in this example, it’s a function that we created in our class in the Container component/file. We invoke this function in our render(), which shows the user each object on the page.

What if we swapped out all of this long array of the object we are getting from the API with a much more reduced or filtered array. We have the information from the button the user clicked right? We could compare this value in an array method that maps the array to objects the user wants to see/how they want to see it.

Let’s create a conditional based on the searchType, we set it equal to our first option’s value in a string. Next, we create a variable, in here we want to create an array the user wants to see. In this example, it’s a straight up match, but it could be a variety of different things. We will go with a .filter array method and put it on our API data, which is saved to our state in container.

Inside the .filter, we are saying the following…

  1. let’s call each index value of this array “element”

2. next, for each element you’ll iterate through, I wanna see the value of element.number

3. let’s grab the value of this.state.searchTerm(the value we saved/what the user wants ! )

4. if what we are comparing is STRICTLY BE THE SAME as element.number

5. gimme those objects in a new array!

Now we refactor our .map to this new variable. This will create an ObjCard with an id, which holds the info of a singular object(an individual object from the API DATA, it’s an element! ) and it passes it down to the Object component when it’s invoked in Container’s render().

You can do this for each radio button you’d like to create. Since in this example we created three, we will do three. Typically, you would want one button to display all information, while the other buttons would filter down this information. I’ve factored the code here to reflect that, but it’s really the dealer’s choice. These buttons should help accomplish the functionality or feel you are trying to achieve not so much a hard-fast rule.

Look upon my works ye might and despair ?! It looks intimidating, but it’s pretty simple, trust me you got this!

Thank you for taking the time to read this, I hope it helps you further understand React.js, Radio buttons, and how Data behaves in this Data Structure. Keep Learning and Coding!

Links on React.js Topics:

State and Life Cycles:


More on Radio Buttons:

Career Changer, Software Engineer & Web Developer