Conditional Rendering in React

I started this week wanting to do something fairly simple. Like almost anything with CS, I began by thinking “It can’t be that hard”. Three days later, and I finally figured it out.

What Am I Doing?

I’m building a React application as part of my capstone project. The React project is build right now so that when a user wants to see something related to their contacts or skills, they do so by navigating between various “pages” through a react-router. This is fine for MVP type stuff, but this is capstone, right? Shouldn’t we have a more polished and professional presentation? I thought so, so my idea was to load this info in a “feature-pane” that slides out on the right hand side.

My vision was this: a user has a main homepage that displays an overview of their data. When they want to edit some part of that data, they click on it in the homepage. After clicking, a window would slide out from the right that would contain detailed information about that specific piece of data. The user could edit it in this window and hit “submit”, and then the window would slide back and become hidden again.

My Approach

The figure below gives you an idea of how our App is structured currently. You’ll see that we have a top level div, under this we have a header, a navigation bar, and then we finally get to our main content. The main area is where our pages load when different routes are visited. We’re not actually visiting new pages with these routes, we’re just replacing what’s in the DOM with these React functional components. So anyways, my two main questions at this point were – 1) where do I put the hidden window, and 2) how do I make it so that this window slides out from the right and overlays the current window (i.e. everything doesn’t slide around when it pops out)?

Starting point of application structure.

I’m going to start with #2. Some quick googling found some tips around CSS animations. Basically, what you do is, on the component that you want to slide in/out, you create a class name that’s unique to that component. From there, I defined that class in CSS as having the following properties:

CSS properties of the sliding window.

The definitions are pretty self explanatory, but the important ones with regard to animation are animation-duration, and animation-name. The animation-name property is then tied to a CSS keyframe, which defines aspects of the animation. There are a lot of in-depth explanations floating around online, but here’s how I defined my CSS keyframe. Note that the @keyframe is followed by the animation-name.

The keyframe that defines the animation over time.

The phrases from and to in the keyframe are short for time=0s to time=end. So basically, at time = 0s, the margin-left of the component with the animation is at 100%. This means that the component will be off screen right. Great, now at time = end, the margin-left will be at 0%, meaning the component will be visible.

I still had to figure out how to get it so that it looked like the window was above the rest of the screen, however. To do this, I started looking into stacked contexts in CSS. To create a stacking context, you need to have positioning of your page elements be something other than static (the default). MDN has a great article for understanding the details, but the main thing to take away is that stacking doesn’t work out of the box. You have to intentionally define positioning for it to work. You can see in the CSS clip above that I chose absolute, which means that my component will be positioned at the exact coordinates that I pass it. What are those coordinates in reference to though? Great question, the coordinates that you pass it are from its closest positioned ancestor. It’s confusing, I know.

It took me a while to figure out what this meant and the subtle implications that it has. Basically, if you have something like this:

Demo of stacking

Then when you try to position your “stacker”, the position isn’t going to be from the top left corner of the parent container. Instead, it’s going to be from the top left corner of the grandparent container. This is because the grandparent is the first ancestor that doesn’t have a position of static. In other words, it was the first ancestor that was deliberately placed on the page. Therefore, the CSS developers decided that this should be your reference point when passing coordinates for positioning. It makes sense once you see it in this light.

Once I understood this, then it was a matter of laying out my components properly so that my sliding container’s parent was the top level div. The top level div is the first element to be positioned, so my positioning of the sliding pane would be with respect to the top left corner of the screen. This is the answer to #1!

I still have some more to go on #2 though. Now the question became, how do I toggle this slider? If I were to just slap that class on the slider component, then every time I loaded the App the slider would slide on out. This isn’t what I wanted. Instead, I wanted it to remain hidden until I clicked something.

Enter Conditional Rendering

This isn’t really conditional rendering per-se. Instead, it’s using state in the component to control the class name that’s given to a JSX element. What I decided to do was use the useState hook in React to store my class name, and give it an initial value of “hidden”.

I then injected that value of state into my JSX element like so:

Using useState means that I can change that class name to whatever I wanted throughout my app by calling the setter function that’s returned from useState.

By doing it this way I can pass the setter function to various components in my app. Then, when I want to change the class name I can simply call the setter and pass a new class name. This will re-render the App and change the class name, which if the class name matches feature-pane will trigger the animation.


That was a wild ride, and it took a lot of trial and error to figure out exactly how to get it done. Here’s what the final code looks like, you’ll notice that I put the feature-pane right underneath the top most div, so that my positioning is correct:

The final result after adding the sliding feature.

There’s still one more gotcha that I didn’t explain that has to do with how you set your display in CSS on the initial class. You have to use hidden or else you’ll encounter a strange flash of a component that then disappears right before starting to slide out from the left. I’ll leave it to you to figure out why this is occurring because I think we learn the best by troubleshooting issues. It’s a pretty easy issue to figure out once you understand the mechanics. In any case, I hope that you enjoyed learning this with me.

Becoming a Programming Polyglot

It’s been a long journey, but I feel like I can finally call myself a programming polyglot. Over the past two years, I’ve developed an understanding of Python, Javascript, C, Go, and am starting to dip my toes into Dart. I’m not sure if this holds true for spoken languages, but I feel like once you learn a couple of programming languages you can pick up new ones quicker. In this post, I’m going to share the path that I took and a few things that I learned.


What first drew me into computer science was web development. I had some time on my hands and was curious what a boot camp would have to offer, so I signed up for a Udemy “boot-camp” course and started banging away at static HTML pages. This was cool and all, but it didn’t get really interesting until Javascript was introduced. One of the biggest takeaways that I got from that class was that everything is an object in JS. This is a concept that has spilled over into other object oriented languages, and I didn’t know it at the time but it’s helped me pick them up quicker.

The boot-camp class was setup where you had weekly projects that you needed to complete. To complete these projects, you could either code along and learn as you go, or you could try to do them yourself and then watch the videos to see the correct way of doing it. Being the first language I learned, it took me forever to figure out and remember the syntax. I was super tempted to just code along, but I noticed that coding along was kind of like eating junk food – it felt good (to see the progress), but in the end I didn’t really see any benefits. I would forget how to do things quickly. I learned that you need to attempt projects on your own first. It’s going to be slow going and frustrating for sure, but the lessons you learn are going to stick with you.


Like any self respecting newbie to programming, I moved to Python next. It’s just so dang beautiful and intuitive to work with. Python is very similar to Javascript, in that it’s a dynamically typed language and very object oriented. I personally think that this allows newbies like myself to get up and running quickly, but it takes some of the careful thought and design work out of the equation. Now that I’ve moved on to statically typed languages, I’ve missed this flexibility.

There are a couple of things I learned when programming with Python. The first was that every language has its own idiomatic way of dealing with common programming operations. With Python, those are things like list comprehensions, using the in operator, enumerating through a list instead of keeping track of your own index value, and the list goes on. The only way that you learn these things is by looking at other people’s code. Thankfully, I had an internship that was almost exclusively in Python, and there were some hardcore Python fanboys on my team. They taught me the basics and I learned a ton by reviewing their code.

This leads me to the second thing that I learned – having code reviews is invaluable. In school, unfortunately, you don’t get many thorough code reviews, and you don’t really see other people’s code to compare/contrast and learn from. I suffered from “imposter syndrome” because I didn’t have a gauge on where my code quality was compared to my peers. If you can, get someone to review your code, or spend time reviewing others’ code. You’ll learn a lot.


You definitely should not learn C as your first language, but believe it or not, I think it’s important to learn C. For one, you’ll feel like a purist. Like fly fishermen and archery hunters, you’ll look down with disdain on the Neanderthals that rely on more recent languages. I’m kidding. In reality, you’ll be wondering why you ever started learning this language, and you’ll miss all the nice built-ins like garbage collection and memory management that Python just magically takes care of for you. But, I wasn’t joking about its importance.

Coding in C really changes your mindset. You have to consider a lot of things that other languages take care of for you like memory allocation, overrunning arrays, cleaning up memory, using pointers to access memory, etc. The main thing that I learned from C is I feel like I understand what is going on behind the scenes in other languages. I entered the OSU CS Post-Bacc program because I was craving this knowledge, and boy did I get it. With C, more than any other language, you have to dedicate yourself to troubleshooting issues, and you have to reach outside your comfort zone. With other languages, there are no shortage of videos and online tutorials to walk you through common scenarios. You can do a lot of programming in those languages without understanding the fundamentals of how a computer operates. I didn’t find much of that with C. Instead, I spent hours trying to read man pages and making sense of what they were talking about. Then I would sit down and try, ever so slowly, to step through my program. It was brutal, but effective. It really helped me focus on what I was trying to achieve and what pieces of the language could help me get there.


Go is like if Python and C got together and made a child. I love coding in Go. When I was first introduced to it I was pretty overwhelmed. My intro to it was in a production setting, and I felt like I needed to learn it quickly in order to perform up to expectations. This mindset, however, discouraged me when I didn’t see my understanding progress as quickly as I liked, and it ultimately led to delayed understanding because I was trying to cram everything in. I learned that it’s going to take time and you need to be patient. Focus on learning something new every day. I also noticed that I don’t learn very effectively (at first) by reading others’ code. Once I have the fundamentals down then yeah, I can learn from doing code reviews, but if I don’t have a solid grasp of the language fundamentals, then I get lost in the jargon. I had to put time in outside of work to get my hands dirty with the language. I did this by doing LeetCode questions in Go and creating some basic data structures (like trees and heaps). It was a simple but effective solution.


I’m currently learning Dart in an effort to learn more about mobile development. I’ve been thinking about my best learning strategies and what I’ve learned from the past. Putting all of the previous discussion together, I’m going to focus on the following:

  • Attempt projects on my own first – don’t just follow a code-along
  • Seek out code reviews
  • Learn the languages idiomatic ways to efficiently complete tasks (through code reviews, but also through the docs)
  • Reach outside my comfort zone and stretch beyond base requirements on assignments
  • Have patience and try to learn something new every day. It’s going to take time and you can’t cram it all in to a week or two.

Hopefully, with these principles in mind I can be developing mobile apps in no time!

Hello Capstone!

Hello everyone and welcome to my capstone blog! The goal of this blog will be to discuss unique challenges that I’ve faced over the term and provide some sort of reflection on things that I’ve accomplished. For blog post #1, I’d really like to share what I think is necessary for a group project to be successful.

A History of Group Projects

Ask almost anyone who went to college how they feel about group projects and you usually hear the same response, “Ugh, I haaaaate group projects. They’re the worst!” It’s universal. Almost as unshakable as the law of gravity. In fact when I hear someone say that they liked group projects in college my suspicions of that person are heightened. Why should I trust someone that actually liked group projects?

I mean, we know that the only people that like group projects are the free riders, right? The rest of us (the normal ones) are scarred from late nights trying to throw something (anything) together to be able to turn in because our partners were too lazy or procrastinated too long to be able to do their fair share. It’s because of our partners, we tell ourselves, that we hate group projects. If our partners were just “better” then all of our problems would disappear.

I used to think this way while I was pursuing my first degree in Mechanical Engineering. However, after I graduated and started working for ExxonMobil, I realized that the problem wasn’t with my partners. The problem was with me and how I approached group projects. Throughout my years of working I’ve been on too many teams to count. Some were successful, others crashed and burned. Luckily for you I’m going to share what I’ve learned from these experiences so that you hopefully don’t have to repeat my mistakes.

From what I’ve experienced, there are no bad teams only bad leaders. What I mean by this is that everyone chooses to come to work every day, to try to better themselves and the team. Sure, some people are more motivated than others, but with the right guidance and realistic expectations any team can be successful. There are endless varieties of books around the topic of successful teams, so I can’t cover everything. However, I think the majority of the knowledge out there boils down to 4 simple practices that, when implemented, take care of a lot of the heartburn that comes with group projects. These 4 simple practices are:

  1. Establish Connections (the golden rule)
  2. Set Clear Expectations
  3. Practice SMART Goals
  4. Communicate Honestly

In the sections that follow I’ll attempt to explain why each practice is important, and what types of problems it will address.

Establish Connections

Be honest, in those group projects that you hated, did you really feel connected to your teammates, or were your teammates just NPCs along for the ride? How do you feel working for someone that views you as a number that’s helping them get farther in life?

I suspect that the answer to both of these questions is no. Here lies the problem at the heart of most short term group projects – we don’t take the time to invest in the relationships. I think that this is the main reason that we all dislike college group projects but seem to be fine with group projects in the workplace. What changed between the two? You see your coworkers every day and are forced to build connections whereas you only see your group partners maybe once a week for an hour.

I know that I work a lot harder for people that I feel connected to. I’m more willing to ask someone if they need help and check in on their progress if I feel comfortable with them. I’m also more honest about my progress and shortcomings and more likely to ask for help when needed. So if you only follow one of these practices, make sure it’s this one. Take the time to get to know your partners on a more personal level and realize that they’re a fellow human struggling with their own issues just trying to do their best. Meet with your teammates more than once a week so that you form those bonds, and don’t only talk about the tasks at hand.

Set Clear Expectations

Admittedly #2 (Clear Expectations) and #3 (SMART Goals) are fairly similar. However, there are some key differences that I think are worth talking about. When I say set clear expectations, what I’m saying is that you should lay out what’s going to happen if you or your teammates fail to meet certain obligations (i.e. the consequences). This establishes accountability and prevents someone from feeling blindsided when the consequences kick in. These consequences are inherent in a workplace setting (you could get fired, never promoted, etc.), but in a less formal setting they need to be spelled out.

During my first degree I was involved in trying to establish a new Fraternity on campus. As part of this process, your group must meet certain criteria for GPA, club involvement, and philanthropic involvement amongst many others. When we first started, we had no accountability measures in place and relied on the good will of our members to meet their obligations. Guess what happened – we failed on almost all fronts. It was humiliating but an important lesson in setting clear expectations. Once we established the minimum expectations and accountability measures if not met, then our members started meeting and exceeding these expectations. Those that didn’t meet the standards weren’t surprised when they were held accountable and actually respected the group for holding them accountable. It also eliminated a lot of the resentment some members harbored from a perceived lack of accountability for poor actions.

So how do you set clear expectations? This goes back to establishing connections – talk to your teammates about what can go wrong and what will happen if you don’t meet certain deadlines or obligations. Be open and honest, and make sure everyone is comfortable with the guidelines in place so that they don’t feel as if they’ve been treated unfairly.

Practice SMART Goals

I feel as if everyone knows what SMART goals are by now, but when I was introduced to them in college it changed my life and how I approach my goals. If you don’t know what SMART goals are, then here’s a handy cheat sheet:

If you use this method of thinking with every deliverable, then your team can’t help but be on the same page. Gone will be the days of excuses, and you’ll gain a lot more confidence asking a teammate about their status when there’s a clear due date.

Communicate Honestly

At the end, but certainly not least important, is communicating honestly. If you’ve done a good job of establishing connections, setting clear expectations, and practicing SMART goals during discussions, then this should come naturally. However, we all feel the pressure at times to fudge the truth in order to make ourselves look better or to divert attention from our issues. We don’t want to be the weak link, right?

Team killers are those that don’t communicate honestly. Some of the most frustrating people I’ve ever worked with deliberately misled stakeholders. The truth catches up to everyone, and your job (and the job of everyone around you) gets a lot harder when people don’t trust you.

I have to admit that communicating my shortcomings and struggles has been one of the hardest parts of being in a group project. It’s humbling and uncomfortable. However, the more honest you are the more likely you are to get help when needed. It also builds trust amongst the teammates and establishes connections (we’ve come full circle… nice!).


Like I said before, there are numerous books and lectures on the topic of building great teams. I can’t begin to say that I’ve covered it all, but I think that I’ve covered the start of it. It all comes down to building connections, communicating in an open and honest manner, and holding each other accountable. I know that I’ll be applying these principles throughout the capstone project, and I know it will relieve some of the stress and frustration that seem to present themselves in group settings. Who knows, maybe I’ll be the one drawing side eye glances when I say, “Hey I liked my group projects!”