DEV Community: jbrochu1

Fully Initiate Your State To Make React Render Your Data More Easily

jbrochu1 — Sat, 07 Jan 2023 06:14:39 +0000

One thing I learned (a few times) over the past few weeks is what to do to do when React gives an (unexpected) undefined error for no apparent reason about heavily nested state objects. A simple .map method being attempted on a an array returns something like:

TypeError: Cannot read properties of undefined (reading ‘map’)

A troubleshooting observation of my console log results: the array would be initiated with some of the important values (my IDs and foreign_ids) would initiate as strings. And the console would log these items not just twice as React often does, but sometimes three, four or even six times before the expected values would finally populate instead of the empty strings I initiated the nested state objects with.

Sadly this happened to me quite a few times with other methods and functions as well as simple renders. Even more odd, sometimes when I would I have the app open in my browser, the data would render in my component right after saving but a page refresh would return the error. So in summary, I knew the syntax was likely NOT the issue as it render on the page momentarily. The data was getting from point A to B (turns out it had to also stop at C, D, E and more in React).

A couple unsuccessful solutions I also tried:

Moving the state to a higher level component and passing it as a prop, nope
Trying to render with callbacks in higher level components, exact same issues
Changing the database to have some of the objects be slightly less nested, sometimes but not always

The conclusion I came to was that React didn’t know the exact data type of my state when I initiated it. I had:

An array of objects
With nested objects
And nested arrays of objects
All with multiple data types
And some integers initiated as strings

So trying to be as efficient as possible I would enter just enough information of the objects that would allow React to .map it to render it. And this would fix the problem until I moved to the next feature. So more specific I would get on the nested objects expected data. Here is what my final useState array of objects looked like so that all of my features would render:

const [trips, setTrips] = useState([{
    id: 0,
    user_id: 0,
    mountain_id: 0,
    trip_start: "2022-10-15T18:30:00.000Z",
    trip_end: "2022-10-15T18:30:00.000Z",
    comments: [],
    mountain: {},
    users: [{
        id: 0,
        username: "",
        first_name: "",
        last_name: "",
        email: "",
        avatar: "",
        age: 0,
        neighborhood: "",
        admin: false,

    }],
    user_trips: [{
        id: 0,
        user_id: 0,
        trip_id: 0,
        user: {
            id: 0,
            username: "",
            first_name: "",
            last_name: "",
            email: "",
            avatar: "",
            age: 0,
            neighborhood: "",
            admin: false,
        }
    }],
  }]);

So in summary my recommendations:

Fully list all of the objects (and arrays and arrays of objects) inside of your state
Make sure you initiate with the correct data type too (no strings when an integer will be used for IDs!)

Most likely the why, per my understanding, is that React has to make multiple passes through the data and functions before it fully renders in your app. It makes initial allocations for the data, then looks at all the functions, then attempts to process the functions with some of the data provided, then iterates through all of this until it finally returns the result to the allocated memory allocation.

And when the data is nested heavily and the data types are not fully defined it takes many passes before the data gets allocated. React will (in my case here and on other projects I have worked on) just throw an error essentially saying: I can’t map through your array because I have not had a chance to put the data there yet to map through it.

Hopefully if you are struggling with the same mysteries this will help send you in the right direction to get that data rendered!

Thoughts on Data Flow and Troubleshooting

jbrochu1 — Sat, 10 Dec 2022 04:51:19 +0000

Have you ever been attempting to write an application and struggled to get your data from point a to point b? You already know how the feature should be structured and you’ve maybe even developed multiple variations of the same one many times. But it…. just..won’t…render…on the page! If you haven’t guessed this happens to me quite often. In fact it reminds me of something that happened often before I got into software engineering.

How does that relate you ask? My previous career path involved a mechanical engineering degree and a quite a few jobs with fire protection engineering. It required doing a lot of hydraulic calculation in computer programs to help design building systems. Troubleshooting was needed almost constantly.

The fire sprinkler systems deliver water to the sprinkler heads and there has to be a certain flow and pressure to spray enough water to put out the fire as intended. The software that exists is not the most polished or user friendly. There were only a handful of platforms on the market and they each had their own issues. They had a plethora of common bugs or unnecessarily difficult to navigate challenges in my opinion.

For example, when connecting the pipes in the drawing to flow water from the source to the sprinkler head, the software was incredibly particular with place the ends of the pipe in the exact location on the screen. More simply put, if you clicked the tiniest fraction away from where the program needed you to click the water would not flow in the simulation. If you were designing a giant building and not paying very exact attention it would be likely that you would have multiple instances where the water would not be flowing where you needed it to to prove your calculations.

You might be thinking, why don’t you just be extra careful when placing the pipe? There were so many other possible ways that the program would have strange glitches that would have the same effect. For example if you move a fitting one foot to the right and then move it right back to the left it would randomly not allow water to flow through it. I could name at least a half dozen other strange issues that would unexpectedly cause one issue or another that prevent you from getting the data you needed to submit a complete your engineered product from getting completed and to move forward with construction.

So what does this have to do with software engineering? I could summarize it with 2 words: debugging and troubleshooting. Similar to a console log or binding pry or breakpoints (whatever you want to call them) I learned long ago a pretty good way to approach this. Find a way to inspect the data incrementally along the way. Much like a debugger I would have to move the source as close to the sprinkler head as possible while the water was still flowing to find the nearest issue and fix it. And then continue down the line until the source was simulated at the further point where it needed to be and have the full simulated calculation be accurate.

Software engineering so far has required me to do much the same when my data is not rendering how I expect it to be coming (if at all) from the back end to the front end. Placing console logs or breakpoints in at various points helps to tremendously to see what the data looks like along its course to the end of its pathway. For instance you can see that what you though was a single array is actually a deeply nested array inside of a nested object. Or that the object is actually making it to your if statement but not the nested if statement inside of it. It was one semi-colon you left in the nested if statement. I’ll leave you with this phrase as a bit of joke but also in all seriousness: “Hello, World!”

Using Migrate and Seed in Ruby (Not Rails) & Active Record to Create a Basic Database

jbrochu1 — Sat, 19 Nov 2022 05:58:08 +0000

To save you the read let me start with telling you a few items that will not be focused on. Do you have a basic knowledge of SQL and Ruby? Do you also have some experience with object orientation and table associations? Great! I will not really be getting into those details but focusing more on how you can conceptually setup the database with Ruby and ActiveRecord. To keep things more concise I will also skip the ActiveRecord setup details and assume you will be able to track those down easily enough.

In Ruby / Active Record the processes I will be going over are called migrate and seed. The intent is to give you a brief overview of how to utilize these processes to streamline your setup.

Before I do that, let me distract you one more time in an attempt to give you my basic conceptual understanding of how a server application can be arranged to utilize a M V C architecture. First here is what M V C stands for:

M = Model: this is where the the methods (aka Ruby functions) live along with the associations.
V = Viewer: this is the frontend most likely, it is where the user will be able to see and interact with the data as we would intend them to through some type of user interface.
C = Controller: this is where incoming fetch requests can be handled how we want them to be.

So a little more on the model as that is the majority of the file types we will be focusing on. Before defining any type of methods it is vital to get the basic structure of the database established. Here is what a simple setup could be structured like:

You must know what data you want to work with and what type of data each will be. Some basic associations will need to be established so that the data can be connected between the tables. If the associations are not setup properly your requests for data will not include all the info you want it to.

A good starting place to learn this is here: https://guides.rubyonrails.org/association_basics.html.
The most common associations are belongs_to, has_many, and has_many through. Although there are a few others these will likely be the most used.

Another tool to utilize are association diagrams. They can be very helpful to visualize your flow of data and they usually look something like this:

Once this has been sorted out you will then define these associations in the models. Each model will look something like this:

In addition to the associations you can see that the top line is calling on ActiveRecord: :Base. This is one of a handful of ActiveRecord setup steps that I will not get into.

Next up: need to create our tables by setting up the data fields and data types that were decided on in the association diagram. We need to run 2 commands:

create_migration
rake db:migrate

The create_migration is essentially going to initialize a blank (but named) database table without any columns. It will also create some datestamped migration files. We will use these files in the next step. Note that we have not actually done the migration yet. We are getting things setup to migrate.

Continuing with our migration preparation, we will take those data labels with associated data types and enter them into our newly created datestamped migration files. In a nutshell, these entries will be the columns of your table (think like a table header).

Now we have our migration files setup. Time to migrate! Run the command rake db:migrate and your columns and column headers will now get populated. Wohoo!

Ruby will expect the entries into each column to be of the datatype you specified. On to seeding! Creating a seed file will help you to generate some data into the rows of your columns. You can think of it as a batch data entry of some preliminary data that you can use to test out your database in Ruby.

Aside from seeding being a batch entry, you can also use it to reset your database to its original setup while testing. For example, if you are testing the backend persistence of a delete feature you may want to repopulate the data you just deleted. Or if you are like me you may find yourself entering asdf lkjh 123 456 in your inputs for backend persistence you may end up with a bunch of garbage entries. Reseeding will allow you roll it back to that original starting point.

The last step you should need to take is rake db:seed. The data should then get populated and you’d be ready to start testing. If you have a database viewer you should be able to see something like this now.

All done! Hopefully this conceptual overview will be give a better understanding of the purpose of using migrate and seed.

When useState Is Asynchronous & Some Ways To Coerce React Not To Wait

jbrochu1 — Fri, 04 Nov 2022 16:26:00 +0000

Have you ever had the situation with a React application where your Components browser tool was showing you the useState/setState data you expect immediately upon your event but the application doesn’t render the data until an additional click is performed? That is exactly the situation I personally found myself in last week. The application was a matching game and some desired features were an attempt counter along with a matched counter. These 2 particular features were to be updated immediately with an onClick event.

Here is a more detailed explanation of what I experienced. See the browser inspect screenshot and initial code as well for more context. Hook #3 (totalAttempts) would update immediately as expected upon the event trigger (this was a simple counter to keep track of the number of attempts). #4 (matchCount) was also a simple counter that was supposed to be triggered immediately if 2 different useStates matched (matching the image name with the displayed text name). However, what actually happened was the useState would not register the match until an extra click occurred (so 3 clicks total to match 2 items). The React rendered onscreen the same as described above with an extra click needed to register the match.

export default function GamePage({animals, onAdd}) {
    const [chosenName, setChosenName] = useState("1");
    const [chosenImg, setChosenImg] = useState("2");
    const [chosenCount, setChosenCount] = useState(0);
    const [matchCount, setMatchCount] = useState(0);
    const [totalAttempts, setTotalAttempts] = useState(0);
    const [isVisible, setIsVisible] = useState(false);

    const HandleChosenName = (name) => {
        setChosenCount(chosenCount + 1)
        setChosenName(name)
        setTotalAttempts(totalAttempts + 0.5)

        if (chosenImg === chosenName)
        {   
            setMatchCount(matchCount + 1);
            resetTurn();
        }
            if (chosenCount > 1) {
                resetTurn();
            }
            else if (matchCount > 3) {
                console.log("game over");
                setIsVisible(!isVisible);
            }
    }

    const HandleChosenImg = (name) =>{
        setChosenCount(chosenCount + 1)
        setChosenImg(name)
        setTotalAttempts(totalAttempts + 0.5)

        if (chosenImg === chosenName)
        {   
            setMatchCount(matchCount + 1);
            resetTurn();
        }
            if (chosenCount > 1) {
                resetTurn();
            }
            else if (matchCount > 3) {
                console.log("game over");
                setIsVisible(!isVisible);
            }
    }

One of the neat things about React is that any changes to the props (data that is passed around between components) or the useStates (think of these as special React variables), React will re-render the affected components when it detects the changes without additional code.

Unfortunately there are occasionally some not so neat side effects in the way React processes these detected changes and re-renders. My understanding of React under the hood is that the rendering occurs in batches determined by React’s algorithms. I also understood that some renders could be taxing and require quite a bit of resources. Depending on the complexity of the application and the quantity of renders in the queue, some of the renders may delayed until the next batch. This is intended to make React run the application more efficiently. When the render is delayed this what causes the operation to be defined as asynchronous (it is not actually rendering when the setState sets the useState variable until later).

Taking a dive you may also see a handful of other issues that can contribute to this behavior. These will be spared from the scope of this post to keep it more concise but if you want to go deeper look at some keywords of flushing and reconciling in regards to how React works under the hood.

If you do run into a similar situation a potential workaround is to utilize the useEffect hook. This will require React to do a more immediate render. The useEffect hook, for those of you not familiar, will keep an eye on particular states if you specify them in order to do just that. Here is what the code looks like with the use effect implemented.

const HandleChosenName = (name) => {
        setChosenCount(chosenCount + 1)
        setChosenName(name)
        setTotalAttempts(totalAttempts + 0.5)     
    }

    const HandleChosenImg = (name) =>{
        setChosenCount(chosenCount + 1)
        setChosenImg(name)
        setTotalAttempts(totalAttempts + 0.5)
    }

    useEffect(() => {
        if (chosenImg === chosenName)
        {   
            setMatchCount(matchCount + 1);
            resetTurn();
        }
            if (chosenCount > 1) {
                resetTurn();
            }
            else if (matchCount > 3) {
                console.log("game over");
                setIsVisible(!isVisible);
            }
        }, [chosenImg, chosenName])

Now with this simple addition of useEffect, the matchCount useState would register immediately upon the the second click. Problem solved! Hopefully this will come in handy for others experiencing a similar issue!

Puzzled About CSS HTML and JavaScript? How They Can Tie Everything Together

jbrochu1 — Tue, 11 Oct 2022 21:38:21 +0000

Learning JavaScript, HTML and CSS at the same time? Functions, loops, variables, arrays, objects, strings… the list goes on! Sounds pretty overwhelming as a beginner right?! Especially when most of it is like a foreign language! Guess what, they are languages! You are learning how to write the rules for the application to do what you are asking it to. How can you do this without understanding the basic groundwork? Also how can you make it look decent? Patience grasshopper!

While it may be overwhelming at times, hopefully it will bring you some comfort to know that they can all come together with some cohesion (once you get a more basic understanding of how they work individually). Let me try to give you a very brief high level understanding of what each does individually and then allow me to tie it together at the end. Full disclaimer: consider that this technical opinion is coming from a novice software engineering student.

HTML
This is the most basic and primitive outline of website. It gives a very rough layout of placeholders to display to the user. Think text, paragraphs, dividers, buttons, lists, images. You create and display all these items (and others) and define some of their styling in HTML but the process is very cumbersome.

Using HTML only is not easy on the eye these days without the help of other languages to tell them how to look (think CSS). Calculations, math, tasks? Also not so much, think of JavaScript for those items. So what is a good way to think about it? Maybe think of HTML as more of the skeleton or structure that a client interface is based on. While HTML does not do some things (well or at all) it can point to the items that can: JavaScript and CSS.

<html>
<head>
  <meta charset="utf-8" />
  <title>My Title</title>
  <link rel="stylesheet" type="text/css" href="styles.css" />
  <script type="text/javascript" src="./src/index.js"></script>
</head>
<body>
</body>
</html>

JavaScript
Need to do some math with variable? Or want to have something monitor for a mouse click and then perform a task? JavaScript to the rescue! Looping through and pulling data from an object with thousands of pieces of information? JavaScript is at your service! It could loop through with only a few lines of code. JavaScript can even create HTML elements with the data that you just looped through with a createElement method.

This JavaScript code is using the forEach method to cycle through all of the menuData items and automatically creating HTML data that will display on the website when the buildMenu function is called. This could be hundreds of lines of code that would need to be manually entered in HTML all in a half dozen lines in JavaScript.

function buildMenu(menuData) {
    let menuList = document.querySelector("#menu-items");
    menuData.forEach(item => {
        let menuListItem = document.createElement("span");
        menuListItem.textContent = item.name;
        menuList.appendChild(menuListItem);
    });
}

How about if you had a comments section in your interface and wanted a user to be able to add those comments directly to the interface? JavaScript could be watching the “Post Comment” button for you to click on it after you have enter some text into the text entry form. It could store this data in a variable (or elsewhere) and tell the HTML to create a new paragraph with the text you just entered in the text entry form.

CSS
Opacity (transparency), grid alignment, assigning font families to particular regions of your page. Want your text boxes on the left half of the screen to have round edged borders? Let CSS easily tell the web browser how to display that.

While these properties would need to be manually entered to each item in HTML it can simplified into a few lines in CSS. One way to do that is to use a css selector to essentially filter all items of that type and assign the preferred visual characteristics. The CSS code here is selecting all p (paragraph) items and setting a handful of properties for them in a half dozen lines.

p {
      color: red;
      background-color: black;
      font-family: 'Times New Roman', Times, serif;
      font-weight: bold;
      border: #fff solid;
      border-radius: 5px;
    }

Want to be able to scale items appropriately and dynamically as you resize a window? You suspected correctly, CSS has you covered. I’ll spare you the details on how to do that, just know CSS makes it possible.

Summary
Hopefully you were able to get a tiny taste of what each of the 3 can do individually and see that they can compliment the others nicely to create great looking and powerful tools.

Hopefully the takeaway is:

HTML: primitive backbone or structure
JavaScript: engine that can calculate and automate complex tasks (and more!)
CSS: the super styler
All 3: much more powerful and efficient when combined together