Forem: Mez Charney

Prevent Re-rendering, Save Usability

Mez Charney — Wed, 29 Jan 2020 21:01:06 +0000

The last hurdle before graduation at Flatiron School is the Capstone. This is a 3 week project that is supposed to encapsulate most of what we learned in the 15 week program, and create something that shows off those skills. Mine is Imp-Politic, a game that creates incentives for people to participate in democracy through legislative advocacy. My original idea was to create a project that facilitates legislative access to underrepresented communities through education. The idea to gamefy advocacy came from thinking about how to make something like calling your senator less of a chore, and more something people want to do.

Challenges

During the build process, I came across multiple challenges, and re-rendering was one of them. When a player completes an action, they click on a button which opens a modal with a congratulatory message and a reward. One of the processes that isn't visible to the player is also adding that reward to the total points the player has already accumulated. The total rewards are held in state in the app. When state is updated, components re-render themselves. Left unchanged, the modal with congratulations and reward would never be shown, and the player would lose all the components they had opened and the app would go back to its original state. This is where preventing re-rendering in certain circumstances comes in.

Finding a solution

Below is a diagram of my app. While most state and lifecycle methods with fetches are held in the Main component, most of the functionality of the app once a user is logged in happens in the children of the LoggedIn Home Page.

I started out having everything in Main, and passing props down to children components that would change Main state. This meant that every time state changed, the entire app would re-render. My first solution was to use a lifecycle method like shouldComponentUpdate to prevent re-rendering.

The React docs for this method are here.

Use shouldComponentUpdate() to let React know if a component’s output is not affected by the current change in state or props.

My method's syntax looked like this:

 shouldComponentUpdate(nextState) {
  if (this.state.loggedInUserPoints !== nextState.loggedInUserPoints) {
    return false;
  }
  return true;
}

However, because everything was being kept in the same component, this method didn't work for me. I started debugging by moving around where certain methods and state were held, to see if having these things in lower order components would help.

As seen in the diagram above, most components share LoggedIn Home Page as the top-most parent, not Main. While the player's total points are calculated and kept in state in the Home Page, the method that updates them is called in Action Card. By moving these methods down into Home Page and lower, I was able to eliminate the need for Main to re-render every time an action is completed.

Conclusion

While there are a few different ways to prevent re-rendering, such as shouldComponentUpdate or Pure Components, it seems that first figuring out the component structure and refining the placement of state and methods is the best way to ensure an app works the way it's supposed to.

Links

Project Github
Imp-Politic

Beginner Node.js: Many-to-Many Relationships

Mez Charney — Mon, 16 Dec 2019 04:58:51 +0000

For my third (and first solo) project at Flatiron School, I wanted to explore the language of flowers. Being a self-described old lady and lover of Victorian romances, I knew that flowers have meanings, and it would be fun to figure out a way to put together messages with those flowers.

Flatiron School mostly focuses on Ruby on Rails for backend development, and I readily admit this project would have been easier had I stuck with that. However, to get the info on flowers I wanted without having to hardcode everything, I wanted to try web-scraping, and the first tutorial I found used Node.js, Axios, and Cheerio. So I set off on the adventure of learning Node.

Database Set-up

First things first, in order to set up a database, you need to figure out the relationships you'll need to build. Since I was working in thin vertical slices, I knew that I would need a table for "flowers", to host the information on flowers and their meanings I was scraping. I built all the Knex queries and the full CRUD routes for the flowers table.

Once that was complete, and the front end connected, the next step was to create a "bouquets" table. This is where collections of flowers, and the "messages" that those flower collections convey, would be stored. Once those were done, the only thing left was to figure out how flowers and bouquets were connected. What it became is a many-to-many relationship, with a "bouquets-flowers" join connecting flowers to their bouquets.

Once the join table was created, the next coding problem was figuring out how to get the flowers that belonged to a certain bouquet to show up in the bouquets get.

Many-to-many Query

Here's the code for the query I wrote that connects to the bouquets table, maps through the bouquets, and attaches the flowers that are in that bouquet using the join table.

const connection = require('./knexfile')[process.env.NODE_ENV || 'development']
const database = require('knex')(connection)

getFlowersInBouquets(){
        return database('bouquets')
            .then(bouquets => {
                const promises = bouquets.map(bouquet => {
                    return database('bouquets-flowers')
                        .join('flowers', 'flowers.id', 'bouquets-flowers.flower_id')
                        .where('bouquet_id', bouquet.id)
                        .then(flowers => {
                            bouquet.flowers = flowers
                            return bouquet
                        })
                })
                return Promise.all(promises)
            })
    }

In each iteration of the map, a variable called "promises" is created, in which the flower_id that's stored in the join with the bouquet_id of the bouquet being mapped over is attached to the bouquet itself. When this query is run using a GET method, what's returned is all the bouquets, each with the information in its columns, such as id, and name, but also with the flower_ids that belong to the bouquet. This makes it much easier to fetch all relevant data at once in order to have the bouquet show up on the front end.

Sources and Project Links

Web-scraping tutorial using Node.js, Axios, and Cheerio: How to Perform Web Scraping
Another web-scraping tutorial I used together with the first one: Web Scraping with Node.js

Github repo for my floral messaging project: Talk Floral To Me

Partnership in Development

Mez Charney — Tue, 03 Dec 2019 01:41:33 +0000

More than in most other professions, partnership and group work are integral to successful software engineering. While the myth of the lone genius hacker prevails, the reality of working in the tech industry is very different. A vast majority of companies of all sizes use a team-based approach to development.

As a student at Flatiron School, I've been able to experience both partner and team based projects. In my experience, the two main ways a project is coded is either through pair programming, or by having each collaborator be responsible for a feature.

Pair Programming

The Agile Alliance's definition:

Pair programming consists of two programmers sharing a single workstation (one screen, keyboard and mouse among the pair). The programmer at the keyboard is usually called the “driver”, the other, also actively involved in the programming task but focusing more on overall direction is the “navigator”; it is expected that the programmers swap roles every few minutes or so.

My first partnered project at Flatiron was built completely using pair programming. My partner and I planned out each feature together, and coded each one together as well. As beginner programmers, the ability to talk through the code while building meant that our minds were constantly engaged and the code was being proofread as we went. Because we had two brains working on the same problem, we were able to compliment each other, sharing knowledge and skill as we went. For me, the instant feedback of having another person right there was the most valuable part. Sometimes, the methodology involved in pair programming was akin to white-boarding as we went.

Dividing Work by Feature

In my second paired project, we started out using pair programming but once the basics had been set up, we divided the features between us and worked on them separately. We came together every few hours, comparing notes, going over code, and working on styling.

This method involved practicing different skills from pair programming. The independence meant that while my partner was there for backup, I was responsible for that feature, and therefore its integration into the project itself. The responsibility added pressure, a feeling of a lack of safety net, but at the same time, it spurred me to want to research and find the best ways to complete the task. Of course, my partner was available for brainstorming and help whenever I needed her, but when the feature came together and worked, there was a definite feeling of victory. It also made me feel like a contributor, creating a part that was integral to the whole.

Useful Tools

No matter what method is being used for the build, planning is integral to the execution. We were using the agile method as much as possible, planning and building in thin vertical slices, coming together for review, testing, deployment and further planning whenever a feature was complete.

Trello is an indispensable tool in a developer's arsenal. It provides the ability to plan features down to the most minute detail, create task boards that assist with visualization, and track progress.

Conclusion

Both pair programming and individual feature work have their pros and cons. Pair programming bends the power of two brains onto one problem, allowing for instant communication and inline proofreading. However, having two developers work on a feature together means that the project may take longer than if the partners were working individually. Individual feature work offers independence and speed, but also a greater allowance for mistakes and requires time to be taken for separate review.

Regardless of the method used, my main takeaway from both projects was the necessity of "buy-in". Each of the partners has to believe in what they're doing, and the method being used. Agile especially requires that everyone on a team is on the same page, and is working fluidly together.

Anticipating User Input When Building a CLI App

Mez Charney — Wed, 30 Oct 2019 03:12:41 +0000

Getting Started

My project partner and I recently completed our first ever coding project, a CLI App built using Ruby. As a novice in coding, it was really exciting and rewarding to build something other people could interact with. Besides overall concerns about the app working, our biggest challenge was anticipating a user's input, and accounting for variations.

Will users follow directions?

The app consists of a database of planets in our solar system, which the user is able to get information on by entering the name of their current location, and picking a planet from a presented list. Here is the code for the method that asks the user where they're from, and compares their answer to existing planets in the database:

def user_planet
        puts "What planet in the Solar System do you currently reside on?"
        user_location = gets.chomp.capitalize
        solar_planets = Planet.find_by(name: user_location)
        if solar_planets
            puts ""
            user_location
        else 
            puts ""
            puts "Please enter a planet in the Solar System.".colorize(:red)
            user_planet
        end
    end

Because our database only has the 8 major planets in the Solar System, we had to make sure the user could only pick one of those for their current location. We based later methods and calculations on this answer, so had to create air-tight logic around the input. The use of an if...else statement was imperative here, as it allowed us to guide the user to the correct answer. If they picked one of the 8 planets, their answer was recorded. If they tried something funny, like Pluto, or Gallifrey, they got a red message redirecting them to give another answer, and were sent back to the beginning of the method. This way, they had infinite chances to get this right (or at least make the rest of our methods happy).

Y/N Complications

At a different point in the app, the user is asked a series of yes or no questions. While the prompt offers Y and N as answer options, we still had to make sure the logic would stand up to testing.

def distance_from_selection
        puts ""
        puts "Would you like to see the distance to your selection? Y/N"
        user_input = gets.chomp.downcase
        if user_input == "y" || user_input == "yes"
            distance
            print_distance
            puts ""
            display_travel_time
        elsif user_input == "n" || user_input == "no"
            display_travel_time
        else
            puts "Please enter Y or N."
            distance_from_selection
        end
    end

Above, we take in the user's input and convert it to lower case letters using .downcase in order to account for users with a love for capitals, and ones who never use them. In our if...elsif...else statement, we make sure to anticipate multiple options for yes and no, the requested answers, as well as something else that could be entered. The else option prompts the user for a correct answer and returns them to the beginning of the method. Each option has its own internal path of methods that are followed depending on the user's selection.

Multiple Interesting Options

def ending_options
        puts ""
        puts "*---*---o---*---~---o---~---*---o---*---*"
        puts "--*---*---o---*---~---o---~---*---o---*--"
        puts "What would you like to do now? Please select 1, 2, or 3.".colorize(:yellow)
        puts "1. Go back to Planet Menu."
        puts "2. View your Favorite Planets."
        puts "3. Exit Travel Agency."
        user_input = gets.chomp
        if user_input == "1"
            system("clear")
            main_menu
        elsif user_input == "2"
            display_favorites
        elsif user_input == "3"
            puts ""
            puts ""
            puts "Thank you for visiting the Milky Way Travel Agency. Good Bye!".colorize(:magenta)
            system("imgcat ./lib/images/purple_solarsystem.jpg")   
        else
            puts "Please make another selection."
        ending_options
        end
    end

This is the code for the ending of our app. We had to make sure the user had multiple options, and would clearly know what each one did. Each option has a number, and the user was asked to input the number of their selection to proceed. While the if...elsif...elsif part of the logic covers the presented options, the else is there in case of typos or general messing around. It returns the user to the option menu to remind them of the app's desired input. It also gives them another chance to see the adorable star ribbon we coded, of which I'm very proud.

Here's a link to the project's repo: Milky Way Travel Agency

Sources: planet image from Jenny Mottar via NASA