DEV Community: Catherine Hodgkinson

React Local State and Redux State (Without Hooks)

Catherine Hodgkinson — Fri, 31 Dec 2021 23:10:27 +0000

I was recently tasked with adding a feature to an existing original application. The application, however, largely uses a Redux store for state management. So, given the nature of the feature that was added, here's how I used local state in a Redux-managed application:

The project is a basic savings calculator that logs transactions (both deposits and withdraws) and tallies the total amount saved at all times. Each transaction is associated with a goal, or reason for allocating the funds. The app also contains a search page, among other attributes.

Through use of React Router, I have all of the transactions logged displayed under the "Transaction History" page, a.k.a. the route "/transactions" in the url. The task given to me was to add a button to this page that would sort the transactions by amount when clicked, and when clicked again, re-displays the transaction list as it originally appeared.

Like I mentioned, the app's state is being managed by a Redux store, with the exception of a controlled form for adding a transaction, which uses local state. I knew that adding this button should also be something that has its own local state because the list being displayed is directly dependent on whether or not the button has been clicked to sort. In other words, the local state being used only in the button is what determines the list being rendered in the browser. So, I added this short declaration of local state inside of a component that is also tied to state being managed by the Redux store:

state = {
      sorted: false
    }

With this, we have a baseline for the state to use in the context of this sort button.

Now of course it's important we actually have a button to work with, so I set the button up as follows (again, within the context of a larger component):

<button onClick={() => this.setState({sorted: !this.state.sorted})}>Click to Sort</button>

Here, I'm allowing the button to be toggled, by clicking, to change the value of "sorted" from state from "true" to "false" and display the data accordingly.

Further, I then implemented a ternary statement testing the condition of state in order to know what should be rendered. The ternary basically states that if the value of "sorted" from state is equal to "false," the data should display as it normally does. However, on the inverse, when the button is clicked, the local state is set opposite and the data is displayed, sorted by amount from least to greatest. Here is what the ternary looks like:

{this.state.sorted ? sortedTransactions.map(t => <TransactionCard key={t.id} {...t} /> )  : this.props.transactions.map(t => <TransactionCard key={t.id} {...t} /> )}

I am using the return value of sortedTransactions if the value of "sorted" is true, whereas otherwise I am pulling the transactions from the Redux store by way of both the connect() function and mapStateToProps and displaying them as they do by default. Here is what the sortedTransactions variable looks like, for reference:

const sortedTransactions = [...this.props.transactions].sort((a, b) => (a.amount - b.amount))

With these steps I was able to successfully implement the sort button and complete the task, which strengthened my confidence in mixing local state with Redux state in a React application. It also never hurts to brush up on using the sort() function, in fact I had to read up on the documentation for the function while completing this feature to figure out how to sort the data in the way I was being asked, which was from lowest amount to greatest.

It was also with this project in general that I realized how local and Redux state can be mixed in an application. What I've deduced, is that deciding whether or not to use Redux versus local state can sometimes come down to just preference or importance/weight of the feature, among plenty of other things.

Here are the links to both the front end repository as well as the Rails back end repository:
Front | Back

React-Redux: mapStateToProps()

Catherine Hodgkinson — Sun, 12 Dec 2021 05:13:17 +0000

React and Redux provide us with a breadth of functions with any variety of purposes, but the one I am going to touch on is mapStateToProps. In light of my most recent project, a simple savings calculator built on the React and Redux libraries, I am hoping to offer some insight to others who may have just begun tackling this function and concept.

On a very basic level, this function is doing exactly as the name states, and that is converting the state of a component (or multiple) into the value of props, so that these properties may be called upon within the context of a component for the purpose of rendering in the browser, or otherwise manipulating the data.

mapStateToProps accepts the parameter of state. Now, provided that anyone reading this understands basic Redux components and their functionalities, it is important to note that this parameter of "state" is derived from the Redux store. This is important to note because if I had been using local state with the same goal, this would be quite a different process, in that mapStateToProps is a React-Redux function; it is relying on the use of Redux, among other things. Using a Redux store as my state control center coupled with the Redux connect() function is the way to gain access to mapStateToProps.

In this example, we can see I am accessing state from two different components in the context of another. In doing so this way, I now have access to both "transactions" and "goals" and their respective attributes. Further, this example exploits another key to using mapStateToProps, which is the connect function. According to the React-Redux documentation, (and most simply put) the connect function links the specified React component to the Redux store, and must be imported into the file in which it is being called. This is another way to remember where mapStateToProps's state parameter is coming from. Since the function is being called as an argument of connect(), which is accessing my store, it only makes sense that the state parameter is also being derived from this origin.

Bearing in mind that this function is a reflection of props from state, it is reasonable to wonder how often this function will be executed, and under which conditions. The answer, however, is simple. This function is being called anytime there is a change to state (again, remembering that this is my Redux store's state).

This function returns an object, which is precisely what makes mapStateToProps useful as far as the return value's ability to be operated on. An object can be operated on using dot notation, for example, which is a common way to access nested data.

Once mapStateToProps has been executed, these props may be accessed in the same way props are accessed under normal circumstances like the example from my code below:

Here, I am accessing my transaction data for the purpose of calculating the total of all transaction amounts, stored in an array, using the .reduce() function, and then displaying the return value of this calculation in the browser. What we can see here is that I am accessing the prop of "transactions," representing all of the transaction data accessible to my Redux store's state, and actually am using that to extract the attribute of "amount" from each transaction to be added to the next. My application allows new transactions to be created by the user, as well, which of course need to be added to the "Total Saved" being displayed on the "Home" route. This action is completed, without any re-rendering or refreshing of the browser, based on my components' state being accessed by my Redux store. With this connection, and knowing that mapStateToProps is going to execute on each state-changing occurrence, not only does any new transaction automatically post to the complete list of transactions, but it's "amount" value is also added to the total of all amounts being displayed.

Lastly, in the event the connect() function is being used without a mapStateToProps function, it is important to list the first argument of connect() as "null," as this function expects a first argument of mapStateToProps and will treat it as such.

Here I have linked the repositories to both the front and back ends of my savings calculator application:

https://github.com/katiekatiekatiee/banking-frontend
https://github.com/katiekatiekatiee/banking-backend

Navigating Callback Functions in a Simple JavaScript Project

Catherine Hodgkinson — Tue, 12 Oct 2021 00:36:51 +0000

My first JavaScript project is done. At least in its first final draft, that is. I chose a playlist curator concept wherein anyone viewing the application in the browser is able to view running lists of songs, organized by their genre into playlists. Anyone viewing the application may also add songs to any of the lists as well as delete them. This post is going to provide an overview of my favorite concept in Javascript so far: event listeners.

In my playlist application, we have a single-page app that displays a full list of playlists that have been saved to the database (a Rails API I created on PostgreSQL for deployment reasons later on). A greeting and the list of playlists are all a viewer can see at first glance. However, each playlist is instantiated with an event listener waiting for a "click." This click triggers another function and that function carries out a process and so on. Let's take a look:

Here, right in the playlist constructor function, I am assigning an event listener, by way of a callback function. Callback functions have also proven very useful for the technical reasons of course, but particularly for me they assist with organization. So, moving down to the callback function, I am displaying the list of each playlist's respective songs using the .filter() method and also populating the form for a new song to be added.

Since the song is being added within its respective playlist, it was important for me to determine how to build this association on instantiation of a new song. The callback function I mentioned previously is the gateway to the form for the new song. So, before going further, it is important to note that the form I have created for a new song lives inside of a static function with a few main purposes: the first purpose being to render the form which also begins to handle the submitting of the information, and two event listeners, one for the click on submit, and the other for a click on the inverse functionality, which is deleting a song entry.

So now, with all of this, we have the data being displayed, a form for a new entry being rendered, and the different kinds of clicks being handled. Here is what is happening behind the "submit" event handler:

Here is where the playlist-song association is being made without any user intervention. With some DOM manipulation, I was able to locate the elements necessary for assigning the attributes to a newly entered song. With this information, a song can be added to a playlist successfully and is able to be viewed by other users, without having to refresh the page. On "submit," the song is attached to the DOM under its respective playlist as well as an associated "delete" button.

What is also happening on the frontend is the configuration of this newly-entered object. The method I named createSong() takes on this challenge. I pass through the attributes collected from the form (which I saved as variables), and then a fetch request is required to communicate with the database, ensure the data entered is valid and meets parameter requisites, and save the appropriate data. The fetch request in createSong() (my create function) is rather simple in that the frontend signals the back, instantiates the new object with the provided information, and provided all goes according to plan, carries out any additional functionality appropriate for a fetch request, such as rendering the information and reseting the data in the form.

This process is highly reusable. I have found that being able to navigate callback functions holds me much more accountable for organization in my own application. Understanding how these work and the asynchronous potential and behavior in JavaScript is something I am still broadening my understanding of, but methods like preventDefault() and stopPropagation() have also been helpful along the way.

Find my repositories here:
frontend:https://github.com/katiekatiekatiee/playlist-frontend
backend: https://github.com/katiekatiekatiee/playlist-backend

Using Rails Routes

Catherine Hodgkinson — Sat, 14 Aug 2021 16:20:48 +0000

One of my favorite resources in Rails has become the routes information page, which is accessible under your "localhost," followed by "/rails/info/routes." I have yet to find a better, more technical term for this page, so moving forward the "Rails Routes Page" is what I will be referencing it as. I have just completed a project built with Ruby on Rails, and its primary focus for a user is being able to leaves reviews of various sites. For the purpose of my application, the reviews can be left for any zoos in the country, including the ability for a user to add a new zoo to the database that may not have been reviewed yet. A zoo is associated with a U.S. state which has to be done on initialization, which is where the Rails Routes Page comes in incredibly handy!

For the purpose of this post, I'm going to highlight an example of using a nested route in my recent Rails project, and how the Rails Routes Page helped me reach the solution.

In the context of my application "Zoo Reviews," a logged-in user has access to a full list of states, and clicking on any given state will route the user to that specific state's list of zoos available already to be reviewed. Each state's show page actually routes the user to the zoos index page, where the conditionals have been set accordingly; if the url contains a location's ID integer, then the zoos index page is only reflective of the zoos for that specific location, otherwise all zoos across all states are listed. This means that the route to the zoos index page has a nested component, seeing as the url would contain something like "/locations/5/zoos." When a user lands on a page like this, there is a link available to add a new zoo to the database, but rather than choosing from a dropdown menu of state options, that zoo-location association is already being built. This is based on a variety of factors, so please don't think that these are all of the necessary steps or actions to building a nested route, rather I am looking to showcase the importance of using the Rails Routes Page as a resource.

So, let's say the user has navigated to the state of California's list of zoos ("/locations/5/zoos"). Now, this user has also clicked the link to add a new zoo to California's list of zoos. Here is part of what is happening behind the scenes:

In order to choose the correct route here to ensure that it is in fact nested and acknowledging that automatic association with the specific state/location, I had to refer to the Rails Routes Page. It goes without saying that as any developer builds on their skills, the needs to refer to this page may diminish but especially with more complex associations, having a full list of routes that are available to use as well as the necessary arguments certain routes require is one less thing to worry about.

So, in this instance, as a developer I knew we are 1) adding a new zoo, 2) associating it with a location for the user, and 3) also allowing the ability for the user to add a review by way of a nested form. To get to this nested form for a new zoo and review, we have to direct the application to "zoos/new." To assure it is still associated with the location on creation, we have to use the route dedicated to this action:

Though small in the midst of dozens of other routes, this is the route required to carry out this action. Here, we can see that this route accepts one argument, which is the location's specific ID, which we can also see being implemented in my code above. In all honesty this was eye-opening for me because just by its name, this does not sound like the appropriate route; sounds to me like it would be adding a new location. But the BEST part about the Rails Routes Page is that it lists the controller action in the last column all the way to the right. Here, Rails is indicating that this route actually takes us to zoos#new. This is exactly what I needed here!

The application continues on to not only build the zoo-location relationship, but again allows the user to add a review with the zoo upon initialization. It is important to know that only the review becomes associated with the current-user, not the zoo or location.

Another important aspect that the Rails Routes Page covers that I still struggle with is when to pluralize a model name, and when not to, in the context of a route. In this example, nothing is pluralized regardless of the fact that a location "has many" zoos in this application. As a student developer I have gotten increasingly familiar with names largely being pluralized outside of the model itself in a "has many" relationship, in general terms. However, in this route that is not the case and I am led to believe the Rails Routes Page saved me a great deal of wondering, debugging, and vexation by clearly spelling these things out for me, and that's what makes this a highly valuable resource, too.

Sinatra Project: Virtual Passport

Catherine Hodgkinson — Tue, 08 Jun 2021 02:41:11 +0000

I've built a simple web application, coined "Virtual Passport," that has a variety of features building an interactive user experience. A user is able to create an account or log in, and then add, edit, or delete their own entries, where an entry contains the name of a country they have visited, the dates visited, any "must-see" locations, and a short description of their trip. While anyone logged-in can view all of the countries listed in the database, only logged-in users are able to add, edit, and delete information. Any user is able to see the descriptions and other posted data listed with the entries. Each user has the option to view only their own entries by navigating to their unique profile, too.

Designing the Virtual Passport from a back-end standpoint was not so much difficult as it was informative. Having built out the various models, views, and controllers using conventional Sinatra and Ruby syntaxes like "RESTful Routes" (an architectural structure in software), I am better able to see how these pieces fit together. At first, the concept of a "get request" somehow taking a user to a form and "post request" followed by a redirect so the user is seeing something in the browser that makes sense, all sounded daunting. Below, I am showing how the way this works actually has a logical flow that is used over and over in our daily lives on the internet.

Using the above as an example, we have two requests. These two requests are dictating the way in which an entry is edited by a user (provided the associated models and views are also setup correctly). These requests represent that "logical flow" I mentioned earlier. Here, the get request first validates that a user is logged in, then defines what a country is to the program-- as an instance variable-- so that I can access that entity in the view for the request. The request then assures the specific country being accessed can be accessed by the logged-in user and is concluded with the directions to the edit form.

This takes us to the patch request. The patch request is the route taken once the user clicks "submit," or the equivalent, after editing the entry. The request defines again how to identify the entry, which is by its unique "id," while also authenticating the user. Then, I am using ActiveRecord's "update" method to not only update the record based on the newly input information, but also save the information. Saving the information is not only important for the current user experience, but more so for the future user experience; by saving the input, I mean persisting the data to the database at the root of the program. This ensures the user will see the data presently, and also in the future when they revisit and build on their profile. Finally, the application will redirect the user to the updated page for that specific entry. Seems logical, right?

Luckily, others agree. The way these routes are written and the order in which they are written are all intentional and follow "RESTful" conventions I previously mentioned. This simply means that the routes follow a convention acknowledged by developers that also makes sense for the flow of the program as it navigates through the respective requests.

It is exciting to see an application of my own on in a browser. I chose the virtual passport concept based on my own love for travel and passion for new experiences, but also my own enjoyment in documenting them. In the future, I may revisit this application to add input fields for photos a user may add from their trip, or at some point I could add the ability to link users together that may have gone on a trip together so there is a more shareable experience.

Below I have linked the repository for this project:
https://github.com/katiekatiekatiee/Sinatra-Passport-Project

Bored? Not Anymore.

Catherine Hodgkinson — Tue, 13 Apr 2021 02:29:07 +0000

When the time finally came to begin my first CLI project, I struggled to even pick a subject because of how much data is truly available to us as programmers. Learning about using data from an API and scraping have opened a very important door in my programming knowledge development.

My project, "Bored?," has a variety of basic functionalities like taking in a user's name, asking them to make several selections, and offers them a random, potentially boredom-curing activity to do. It also offers the user the number of participants they need for the specific activity, a rough cost, and the category the activity falls into (i.e. recreational, academic, etc.).

Certain aspects of the project flew easily from my mind to the screen. I knew I was using an API, and I knew the basic format for fetching data from an API, so I knew I could build my API class:

I have also become increasingly familiar with the initialize method, accessing pieces of data through iteration, assigning attribute accessors, and at the very end I quickly picked up on how to use the "colorize" gem in Ruby to change the color of the text that is output to the terminal. Not only was that really fun (which was the only reason I was incorporating it) but I actually found the coloration to be useful in terms of organization and separating ideas and phrases in the terminal. In short, the pretty colors make my prompts easier to read. And let's face it, no one wants to use a plain-looking application!

I did, however, run into an issue that took some time, creative thought, and some instruction to conquer. My code has a "see_more" method, in which some input options can be reused in other places if, for instance, the user is not interested in the activity they are presented with and wants to see a new one. It is a different take on my "menu" method earlier in the program that also has some reusable assets. The problem I was facing involved showing the user that new, or alternate option for an activity. My program was continually printing the same activity over and over and over again until the program was exited. So, I presented the following solution within a method of my CLI class:

This solution allows the program to re-call the API and gather a new set of data. Using the Ruby gem "pry" I could see that the site was only providing a single hash of an activity and its attributes, which was being stored in the class variable and array "all" as an object. The solution was rather simple because of this. I could just clear that array and call the API again to get a new hash of activity data instantiated. It also helps that there is only a small amount of data being loaded every time the API is called, to prevent the user from having to wait with a blank screen (although they are bored so after all that might be a step up?).

I included the cover image of the top of a mountain in my home state because the application includes a possible suggestion of "taking a hike," which is one of my favorite things to do. It also includes ideas like "try a food you never have before," "make a new friend," and "volunteer at a local food pantry."

With this project complete, I find myself confident in what I have learned so far in my journey (now about two months in). I am excited that I have the ability to build projects like this and look forward to building on this foundation.

Beginning of an Endeavor: Why Software Engineering

Catherine Hodgkinson — Mon, 01 Mar 2021 03:28:56 +0000

The story I tell everyone who asks me why I want to become a Software Engineer is that I saw a video on TikTok of a girl who took a coding bootcamp directly out of high school, at Flatiron, and has been wildly successful (and genuinely happy) since then.

The story I don’t tell everyone is that I found that video in a moment of absolute despair. I found myself deeply dissatisfied with my current job and position and lack of advancement opportunities, but also lack of better options. I spent time job-searching to no avail, felt hopelessly stuck, and knew I needed a change, but that idea alone was too broad and overwhelming.

Then I saw the video on TikTok.

So while it sounds funny that a video on social media led me to want to become a Software Engineer, at Flatiron School in particular, I can’t help but feel utterly grateful that this opportunity has found me. At one point I couldn't see any additional time in my full-time work schedule to take on anything additional, turns out I simply hadn't encountered something I was truly interested in. I now want to become a Software Engineer for the endless possibilities that opens up. The technology industry is virtually bullet-proof in the sense that it will be around and growing forever. Having been alive long enough to see different economic conditions and now with the COVID-19 pandemic, I understand more truly the value of a stable and reliable career.

I am always seeking a challenge; I am an avid problem-solver. I am ready to build a lasting future for myself, and am confident that this challenging journey is exactly what my life has been missing. The concept of coding fascinates me to the point that I need to learn that language to further understand that computers don’t run on magic, but that it is truly a machine that is executing what it has been told to do.

I am writing this having just completed a week’s worth of assignments, and luckily that desire for a greater understanding only runs deeper now.