Pushing the Data

Courtney Wilson
5 min readNov 2, 2021

--

In my final project with Flatiron School (still can’t believe I’m saying that), some of my data included a boolean value on the back end. I set up a travel list application where a user can create a new trip they’d would like to go on, it will display to a trip list of all the trips you’d like to take, and once you’ve taken said trip, you can mark it as “Been There”, and it will move the trip to your journal list. I chose to write about this particular feature because it challenged me for a day and a half and I learned a valuable lesson while experiencing that victory. So, let’s get into it.

In order for me to create a trip, I created a table in the backend that would take in certain attributes of a trip including city, country, and importantly for this blog, a been_there boolean (fourth attribute down).

Now, from the front end, every new trip that is created will begin with that boolean set to false, so from the start, a user has not “been there” for a trip (line 14).

To display which trip would show up on which list (“Trips” vs the been-there “Journal”), I mapped through my list of trips and returned those trips with a value of “true” for the been_there attribute. I used a ternary expression, so if the user had been on a trip (been_there === true), it would show up on the Journal list. I wrote this logic in the Journal component this way -

The above example also includes several styling components from material-ui, so ignore that bit and focus on the logic. If the user had been there, the trip will show up on the list in the card component. Otherwise, if false, the ternary expression will return null on the Journal page and the list will be empty. The tripsLi variable is then rendered by calling for it in the return of the component.

The same was applied to the Trips list, where the trips you would like to take are displayed. The only difference here is that I switched the ternary from looking for a true statement to false, so if a user had not been on this trip (which is how trips are created and set as default), the trip card will render here on the Trip list component -

I had used another ternary expression in my trip details card component to display whether or not the text on the card read “Hope you enjoyed your trip.” or a button with the ability to click “Been There”.

{trip.been_there ? “Hope you enjoyed your trip. On to the next one!” : <Button onClick={handleClick}>Been There</Button>}

This was all fine and good for the frontend. I could see the state switching from true to false in my handleClick logic for the “Been There” button I created in the details of each card. But upon refresh, that logic would disappear and the trip would revert back to the default state.

This is where a big lesson was learned —

I had spent so much time on this one switch. I studied over it for hours, to the point where my code just didn’t make sense to me. I forced myself to take a break for the evening and get some distance from it. The very next morning, everything clicked. Of course the expression was reverting.. I had to persist the change to the backend! And I knew just how to do that.

Enter.. the patch request.

Of course it had to be patched to the backend and update the data there! I knew this, but in my efforts of trial and error and pushing my tired mind on and on, I had completely looked over the backend handling. With this simple handleClick logic that takes care of our patch request, the backend changed persisted and my state changed for good.

A patch request is what we use to update or edit our data on the backend. In the example above, I did this by creating a body variable equal to an object, setting it to the attribute I wanted to change, and pointing that value to the new updated state = “!trip.been_there”. The ! for a boolean expression is a “logical ‘not’ operator” and will take the value of the expression and turn to the opposite value. In this case, from false, to true.

And there we have it. A working “Been There” button that persisted to the back end! This was a major victory to me as I actually took the time to step back and think logically about why this wasn’t working. It clicked into place after I gave my brain a chance to rest, teaching me that it’s okay to be kind to yourself and give yourself a break.

I hope this was helpful to anyone experiencing the same problem. Get out there and get to patching!

--

--

No responses yet