DEV Community: william-luck

My Journey Through Flatiron's Software Engineering Flex Program

william-luck — Sat, 29 Apr 2023 18:54:41 +0000

Introduction

If you're wondering if you can complete Flatiron's software engineering bootcamp as a flex student, you definetely and most certainly can. But I hope that I can get the message across that it is not easy, and your life is going to look a lot different over the next 20, 40, or 60 weeks (or 59 weeks in my case).

I originally planned to finish the program between 20 and 40 weeks, but ending up doubling that due to work commitments, relationships, traveling, and becoming an expat in the strange land that is Argentina.

I have worked on completing the program. from Austin, Seattle, Puerto Vallarta, Buenos Aires, Patagonia (even stuffing myself in a cabin for a month to refocus), Belize, and Guatemala, where I am currently writing this post. I have done all of this while doing third-party monitoring of USAID-funded aid assistance in post-ISIS Iraq, which is more remote-work-accessible than you think.

The beauty of this program is that all this is indeed possible, at the price of some measurable level of sanity, but possible nonetheless. I would recommend this program to anyone with a full time job or other serious responsibilities to confront, and those who are clinging to remote work in the face of consistent return-to-office requests post COVID. It is not easy balancing responsibilities, and I would have to count the number of times I’ve had to reschedule 1:1s with my instructor on three hands, when work somehow has the ability to schedule meetings exactly during my 1:1 slot.

Journey throughout the phases:

Phase 1:

From the very start, I immediately began to reexamine normal tasks in my daily life and applying coding to them. I thought about how I could store mundane information in arrays and objects, and once spent an hour to sweep a kitchen in terms on functions and event listeners.

I still believe that this is the most challenging phase. You are presented with something completely new and have essentially re-learn how to think, especially if your someone with no formal STEM education (other than acing physics in high school, thank you Mr. Canafax). I took many notes trying to drill the concepts in my head, but found that I did not use them that much. I freaked out many times, and congratulated myself too early many more times.

Phase 2:

Things are still hard, but I found that it is much easier to learn new concepts and immediately apply them. I wondered why they didn’t introduce React earlier, as it truly makes front end programming easier, and I found myself saying in my head ‘why didn’t they tell me this existed before, this just makes life so much easier and why did I spend all that time learning phase 1 when I could have just been doing this?” A little flawed logic, but if you’re like me you’ll find that half your logic is flawed anyway.

By this time I really began to know the concepts by heart. I hand-wrote several fetch requests on full sized pieces of paper (I didn’t have sticky notes and forgot Amazon Prime existed). I remember once when I. think it then took me an hour and half of thinking through broom sweeps of my kitchen floor, in terms of increments, setting and updating state, and clearing that state whenever I left the Kitchen.

My daily remote work and my remote coding bootcamp became a living application itself, and I began to think of each room as a component and how I could pass information between rooms and deciding where shared state should live so to speak (in the living room most often than not).

Phase 3:

This was the most deflating phase for me, as it felt like I had just been taken several steps back. You start with a completely new language (and the syntax and the code just looked ugly to me in my opinion, big gripe there). There are completely new concepts, such as object orientation, SQL, and relationships between back-end data.

I think I just got frustrated that this phase seemed not be not to be a natural extension of phase 1 and 2, and I often wondered why this information was relevant, especially SQL which still holds a personal grudge.

But just stick with it, things started to click for me when I learned about Active Record and Active Record Associations. Things will ultimately click during the last module of Web API with Sinatra, and I finally knew why I spent close to two months trudging along. The phase is all just really about the relationship between the front-end and the back-end, and I saw the benefit as I started to work through my project.

Phase 4:

I worked through this phase relatively quickly as I finally just committed myself to sit down with the code with nothing else to do, and did so from a small little cabin in the woods (you might not need to go this far, but if you feel that you’re falling behind and not catching up, sometimes extreme measures are warranted). This seemed to balance out anyway, as I took a long break after the curriculum for the holidays and spent a lot of time developing my project.

This phase goes back to the comfort afforded by phase 2 and the prevailing manta of “Hey, things are still hard, but I’m getting a hang of it a lot better now at least.” The lesson of Model-View-Controller is one of the most important conceptual lessons in the curriculum in my opinion. I had similar thoughts of “wait, we could have just been using Rails this entire time?” Again flawed logic, but I now have a deeper appreciation for both phases 1 and 3.

As I worked through the rest of the program, I found myself continuously coming back to the lessons in the early part of the curriculum, especially concerning migrations, generators, routing, params, strong params, and error validation.

Similar to my insanity demonstrated in phase 2 with the oversized fetch requests everywhere, I applied the same with error validation. The fetch requests were replaced with voice memos of the process of the validation. I spent a lot of time in the guides outside of the curriculum and learned much about the roles of each of controller, model, and serializers.

I never thought that before starting this phase this would make sense to me…  

.. but it very much does. These lines concern protecting the database from bad data being saved, rejecting that data with an understanding of just when those validations would be checked, the relationship between dependent resources and displaying nested JSON in fetch requests, and having another resource (menu item) exist without having to be assigned to to parent menu resource.

I explain data validation in more detail in a previous blog post I wrote here.

Thanks to the long break I had around the holidays, where I gave myself permission to finally take a rest and revisit these concepts, and because of the relatively slow pace of working on the project once I began, I believe this project review was my strongest.

Phase 5:

This is where it all comes together, and it is definetely the scariest phase. It kinda feels like you’re forcibly thrown into the pool, but in contrast to the old analogy, you actually know how to swim this time. The pool just happens to be much larger and deeper than you expect.

I struggled to come up with an idea of just what to do for this project, and went through several ideas either ruled out by my instructor or myself. But once I got going, the going got, and it seemed natural enough and fitting enough to finish out the program proudly. This phase gave me ideas on the next scary step: the actual job search. As much it was challenging, I found it be a good reflection of just how I could demonstrate all that I’ve learned in the program, and I feel like I can continue to develop the application even after the program ends (which I guess is kinda the point).

You can check out my phase 5 project here.

A Send Off

To conclude, I’d like to finish with some of my biggest tips for success in the Flatiron flex program. If you’re thinking about doing it, please take these tips to heart. I like to think that I can now speak with some authority on this.

Please Read These:

My biggest tips for any poor soul that stumbles upon this blog post:

1. Relation to Daily Life: No matter the pace, integrate coding into your daily life. You don’t have to code everyday, and I would go so far as to say that could be detrimental. The concepts need time to digest, and proving to yourself the concepts still make sense after some time means that I have learned them, not just memorized them (thank you school tests). Think of how you can think about mundane tasks and chores in terms of JavaScript and Ruby. Say it out loud. Even if people think you are a tad crazy.

2. Work according to your interests and profession: Create projects that are relevant to your interests or work. It makes them much more engaging, and it feels less of a requirement and more of something that you can use. I still use my phase 2 books application for my guilty procrastinations. I then moved to creating applications that are more relevant to my work in my phase 3 and phase 4 projects. They loved it, and we are working now to develop some basic CRM software (sub-contractors in Iraq still use Skype and WhatsApp for important work notifications). My phase 5 project is the most relevant to daily life. I plan to live in Argentina for the remainder of my job search, or until I get something going on my own. The 100% inflation in Argentina wreaks havoc. My local pub has already agreed to start using in some capacity upon completion, and that’s enough of a start for me (but comes with a whole new sense of anxieties).

3. Connection to others: My biggest regret from the program, by either extension of conflicting work schedules, travels, grasping for some semblance of free time, or just plain unwillingness on the false belief that I can do this on my own, led me to not interacting much with other students. Flex students will feel isolated, it’s part of the nature of the program unless there is active effort to not feel that way. I reached out to live students residing in Austin and we had a picnic in the park. That single interaction went a long way knowing that’s actually other human beings experiencing this. You don’t have to meet up, but respond when others are asking about a problem, attend community events, go to office hours. Do what is necessary to feel that connection and shared identity with other students.

4. Program pacing: Truly work at your own pace to the best of your ability. It’s helpful to commit yourself to a pace, but it is not necessary if that creates more stress than it relieves, and if you feel can keep yourself accountable to meet general deadlines you have set for yourself.

5. Pacing of Projects: As an extension of the above, take your time with your projects. Don’t rush it. This is your time to cement your learning and review all the concepts you learned. Do a little each day, not a lot. Even I had no other responsibilities, I think I would struggle heavily completing a project within a week or 10 days.

6. Accountability: If you aren’t in touch much with other students, at least tell others who you trust in your life what you are doing. They can keep you accountable, ask about your progress, and ask about something that you learned. If you’re surrounded by all non-techy people such as myself, this is a really good opportunity to truly explain concepts like they're five. If you can explain it simply, and if they have no coding experience and they can understand it, you’re doing it pretty well (keep in mind these explanations probably won’t work during project reviews and live coding). If somehow the other person is still interested, teach it to them! Maybe you can even perhaps trade Spanish lessons for some basic JavaScript principles, which worked for me until I started to explain things in a way too complex manner, signaling to me that I didn’t really know the concept.

7. Resources: Use other resources outside of the curriculum! The curriculum is not the be-all end-all source of omnipotent knowledge you need to figure problems out. As I advanced through the program, I continuously found the curriculum to be used as a starting point, not the final solution for challenging bugs. Use the resources often included at the the bottom of each lesson. Watch videos. See what others have done and how they fixed it.

8. Working through bugs: Reexamine your relationship with bugs. When starting the program, I thought bugs were a reflection of my poor coding skills. They are not. They can be something as simple as overthinking a concept or simple mistakes in syntax, or they be a strong signal that you are just not understanding a concept all that well. Use your debugging tools, see the values of state as you navigate your applications in the react tools, see how your redux state changes (pro tip, click that ‘diff’ tab and take away approximately 17% of your frustration).

9. Permission for yourself: The biggest tip I can give is patience, and giving yourself permission to be flexible on your expectations. This program isn’t easy, and it wasn’t meant to be. Take breaks, change the timeline on yours goals accordingly. As part of the flex program, no one is going to tell you that you need to speed up (except perhaps on weeks 50-59, and everyone will tell you on weeks 58-59). There are many success stories of new students completely changing gears and getting jobs in less than a year and having a completely new life. That’s great, but it should not be expected, especially when you have other big factors in your life that deserve attention. The biggest plus of the flex program is that ability to be, well, flexible, and you shouldn’t beat yourself up just for being inflexible.

10. Cheeky note: Do your blog posts. More than one per phase. Just do them. Don’t wait until April 29th, 2023 for a March 2022 start date :)

Using Redux Toolkit, and differences with action creators, state updates, and async actions

william-luck — Sat, 29 Apr 2023 15:43:56 +0000

What are the advantages of using Redux Toolkit? I asked myself this question when I had spent a solid week trying to learn how Redux alone could be used in my applications, and then learned Redux Toolkit, which simplifies mostly everything I learned in the week previous.

The most helpful benefits of using the toolkit for me involve mutable state updates, generating action creators automatically, and handling asynchronous fetch requests. There are many more, especially in regard to simplifying syntax and removing much of the boilerplate code to even get Redux up and running, but these three benefits address the most challenging aspects I struggled with in using Redux.

Updating state

I will use examples from a recent application I developed, which involves CRUD actions for ingredients, menus, and products as part of my phase 5 project for Flatiron School.

When I want to add ingredients to the Redux state without the use of the toolkit, I cannot change the state directly, but I have to return the previous form of state with any new additions that override the previous data in my reducer:

function ingredientsReducer(state = initialState, action) {
switch(action.type) {
case ‘ingredients/ingredientAdded’: 
    return {
        …state,
        entities: […state.entities, action.payload]
    }
default: 
    return state
}

Notice the use of the spread operator, I am never mutating state directly, only returning a new form of state to override any changes.

With the toolkit, I am able to write code that appears to mutate state (but not actually doing so because of some behinds the scenes toolkit magic, using Immer library):

const ingredientsSlice = createSlice({
    name: 'ingredients',
    initialState: {
        entities: [],
        menu: '', 
        name: ''
    },
    reducers: {
        ingredientAdded(state, action) {
            state.entities.push(action.payload)
        }
    }
    }
)

The state updates are found under the reducers key in the ingredients slice (using createSlice, which is also specific to the toolkit). Instead of worrying about bug-prone mutable state updates with the use of the spread operator, I can write code that directly appears to push the new ingredient to the state mutably. For emphasis, the toolkit is handling the work behind the scenes to not actually mutate state, but I can write simpler and more digestible code.

But what is happening above with the created slice and specifying the state and reducers?

Generating Action Creators Automatically

Another change in the toolkit is that I no longer have to write out my action creators, and the toolkit handles those processes for me.

Action creators, without the toolkit, are functions that return an action object for dispatching actions to the store. An alternative of the above above when writing an action creator explicitly would be:

function(ingredientAdded)(ingredient) {
return { type: ‘ingredients/ingredientAdded’, payload: ingredient }

With the toolkit, the action creators are generated automatically under the reducers key in the created slice. All we need to do to use them in our application to export them from the 'actions' property of the ingredientsSlice object.

export const {ingredientAdded, anyOtherReducers } = ingredientsSlice.actions;

Asynchronous Actions

When using createSlice, we create an object with keys including name, state (where we store data as normal along with any errors or loading state needed), and reducers (which generate the action creators automatically). Another key we can define is extraReducers.

The difference between the reducers key on the extraReducers is that the reducers key creates those action creator functions and responds to the actions within the reducer. The extraReducers do not create an action creator function, but responds to actions we have defined somewhere else.

Without the toolkit, we would stick with explicitly defining an action creators and make a fetch requests, and return the type and payload depending on the response from the fetch request itself. But since the fetch requests are asynchronous, and even though we can chain a series of .then()s to the request, any action creators will return the action even though the promise has not resolved:

export function fetchMenus() {
const menus = fetch(‘/menus’).then(r => r.json());

return {
 type: ‘menus/fetchMenus’, 
 payload: menus
}
}

Without the toolkit, we would have to import and incorporate redux-thunk middleware by default to avoid this issue, and include it in the index file when creating the store:

import thunkMiddleware from "redux-thunk";

const store = createStore(rootReducer, applyMiddleware(thunkMiddleware));

Then in the action creator, we dispatch actions as such:


export function fetchMenus() {

return function (dispatch) {

dispatch({type: ‘menus/menusLoading’ })


fetch(‘/menus’)
    .then(r => r.json());
    .then(menus => {
dispatch({type: ‘menus/menusLoaded’, payload: menus})
})

}}

Notice that we are not actually returning any actions, but instead a function that dispatches action from the returned function, one for loading status and one for loaded status.

With the redux toolkit, it becomes simpler. We first create a separate exported function outside of our slice, and call this function directly in react components whenever applicable (such as page load, navigation away from the page, on button click, etc).

For this example, instead of fetching ingredients, I am fetching menus which I use to load data whenever the application first starts. We use createAsyncThunk provided by the toolkit, and keep the fetch request in a separate function:

import { createAsyncThunk, createSlice } from "@reduxjs/toolkit";

Then in the extraReducers key, I can handle the loading and loaded status, as well as any updates to state, as such:

There are still two different cases for fetching menus, loading and fulfilled. Each changes state, but only fulfilled will update the state to include the menus returned from the fetchMenus function. This removes the need for applying the middleware explicitly, worrying about the promise not resolving before updating state.

Cron Jobs and the Use of Rufus Scheduler Gem

william-luck — Fri, 28 Apr 2023 20:15:53 +0000

I recently completed a project for my final phase of Flatiron school. It's a software to keep track of the Blue Dollar Rate in Argentina, automatically update prices of food items included on a menu, and recommend pricing.

The GitHub repo can be found here, and the project is also live at https://blue-rate-tracker.onrender.com/

This project depends on the use of a scheduler, and I used the Rufus Scheduler Gem. Schedulers were completely new to me when I first started this project, but the gem helped me to understand cron jobs and how they can be used in my applications.

To update the prices of my menu items, I needed code that could make a call to an API every morning before the business day begins, and update all prices accordingly. I know the code necessary to update the price data, but I was missing code to actually run in the background and update automatically as a background process.

After installing the gem, I added a scheduler file in under initializers in 'config/initializers/scheduler.rb'. Initializers in Rails help to configure your application, and are ran after the framework and gems are loaded. It is crucial to include the scheduling processes in the initializers because I want to the scheduler to run and be set in place before the actual application starts running, since I want recurrent changes everyday by default.

In the newly created file, I first require the gem using require 'rufus-scheduler' and then initiate a Rufus scheduler instance:

require 'rufus-scheduler'

scheduler = Rufus::Scheduler.new

Next I need to write a cron job to execute everyday at a certain time. For the purposes of this application, I want to update the prices everyday at 6:00 AM Argentina Standard Time, which equates to 9:00 AM UTC:

scheduler.cron '00 09 * * *' do


end

Put simply, cron jobs are used for scheduling certain tasks at a specified date (or time, a in this case). In my futile attempts to follow the installation and setup instructions to get this working, I did not fully understand the cron format in its elusive series of stars, blanks, zeros, and numbers.

I used Cron Guru to help me understand the format, where I played with the format until I had a more solid understanding.

To summarize, the format accepts five digits, each used to specify a different time.

The first digit accepts a minute, from 0-59.
The second digit accepts an hour, from 0-23.
The third digits accepts a day of the month, from 1-31
The fourth digit accepts a month, from 1-12
The last digit works a little differently, accepting a day of the week, from 0-6. 0 refers to Sunday, while 6 refers to Saturday.

Asterisks / stars are important to tell the job to completely disregard any specifications to that day, week, or month. But in my case above, I need to specify "00 09 * * ', because if otherwise, putting " 09 * * *" will result in the cron job executing every minute during the 9:00 AM hour (9:00 - 9:59 AM).

Other schedules accepted by the Rufus Scheduler include in and at jobs, which only trigger once, during a specified time. For example, after initiating a Rufus scheduler instance:

scheduler.in '12h' do

end

// or

scheduler.at '2023/04/29 16:00:00' do

end

In each case, the task only executes once, in 12 hours from the time of initialization, and on April 29 at 4:00 PM, respectively.

More useful jobs concerning my application are every and interval, as well as chron. These tasks trigger repeatedly.

scheduler.every '12' do

end

// Or

scheduler.interval '12' do

end

The difference between every and interval is that interval will immediately execute the task, then repeat those tasks at the specified interval. Every omits the initial trigger, unless specified using first_in and first_at.

For example, using first_in, I could have something as follows:

scheduler.every '12h`, first_in '12h' do

end

While the initial trigger is still omitted from every, I can customize a time to call the first execution.

I can also use first_in for the purposes of my application:

scheduler.cron '00 09 * * *', first_in: '5d'  do


end

My full code for updating the prices of the products in my database looks like this:

Notice that the cron job accepts an argument |job|. While I do not have any expanded use of this argument in my application, it comes with useful methods that I can use in conditional logic if there are considerable changes to the blue rate. For example, I can use job.unschedule, 'job.pause', and job.resume if there are changes above 10% a day, for example. This is not too common, but there have been recent jumps such as these. This could be useful to temporarily pause the cron tasks until the price stabilizes, as the rate is likely to fall back down after considerable hikes.

Other useful methods that I could integrate into the application are original, which returns the cron format of when the updates are scheduled; paused?, which returns a boolean telling me if the scheduler is active; and count, which returns the number of times the database has updated since starting. This could be useful to then pause the scheduler for a manual review of any changes to the prices of raw items every quarter, if the prices in markets have either not caught up with or exceeded the blue rate.

Rails validations, Exceptions, and Error Handling

william-luck — Thu, 26 Jan 2023 17:34:43 +0000

What is the difference between .new/.save and .create, as well as their sister methods? (.save! and .create!) When should you use them and how do they relate to the validations in rails? How do you handle exceptions and invalid data when saving to a database?

This blog post assumes some level of rails validation code present in your models. The simplest of validations is that an attribute has to exist on the instance before saving it to the database. For example, I created an application that has a household (or family) as one of the models. For the household to be created, the only thing that has to be supplied from the user is the address of the household.

I can create a new instance of a household using `Household.new’ in the rails console. However, the return value of such is just an empty household instance without any attributes (all having nil values):

Even though I have the validations for address present in the Household model file, rails still allowed me to create the instance because only database activity triggers the validations. We are not attempting to save the household (yet) to the database. From the return value alone, there is not really a way to see if the instance could be saved to the database with these nil values. We could, however, run Household.valid? to see if the data is valid:

The return value of this code is false, which indicates that the data is invalid. If I instead created a separate instance of a household while specifying the address, the data would be valid when saving to the database:

You can imagine a use for this boolean return values in your control flow, using conditional statements. In your controller CRUD actions, for example, you could run the .valid? method before continuing, or return an error otherwise that you could customize to the needs of your application. Continuing on with the two above examples. What will happen if I attempt to save the household instance to the database? Remember that validations trigger upon database activity, so rails will check for the presence of address.

Let’s start with the valid data:

Rails successfully saved our household instance to the database, and calling Household.last in the console will give us our newly created household. In my model, each household can also have a date of entry. However, since I did not include the validations for that attribute in my household model, the instance is still saved successfully in the database.

For the invalid household instance, when attempting to save it to the database, something else happens:

We get a return value of false. Rails does not give us the reason for the valid data by default without some error handling. Calling household.create on this instance and using the return value would serve the same purpose as calling household.valid? for your control flow, but there’s much more room for error, especially if you were expecting the data to be valid and were then calling other methods on this false return value. Unfortunately, with the return value by itself, there’s not much we can tell the user or our program, other than the instance was invalid.

Having rails throw an exception would be more useful, along with an error message of exactly what went wrong when saving the instance to the database. Exceptions can be raised if we make use of .save! and .create! sister methods. .create and .create! combine the use of .new and .save, where rails attempts to create an instance of the household and save that instance to the database in one go. What happens if we use .create! for a new household with invalid data (no address supplied)?

Rails will throw an RecordInvalid exception, along with a useful and simple error message of why the creation was unsuccessful: that the the address cannot be blank. But how do we plan for these errors and exceptions in our code? If we have multiple methods to create and update household data in the households controller, a useful way would be to include a rescue_from ActiveRecord::RecordInvalid statement at the top of our controller, which would kick in if there are any RecordInvalid exceptions in any method, along with a custom class method to render JSON of the details of that error for our front end:

Using the above code, any time that there is an RecordInvalid exception, the render_invalid_data_error method will return JSON with some nicely formatted errors to use in the front end. We can obtain an object of the errors in the frontend with invalid.record.errors, and put those errors in an array with invalid.record.errors.full_messages:

If the data was valid, my application would have returned JSON of the valid household from the server upon creation. Instead, a RecordInvalid exception was thrown, and the rescue_from statement along with the custom method returned JSON of the error itself, formatted into an array. Moreover, notice the 422 error code (unprocessable entity) returned from the server, which we specified with status: :unprocessable_entity’ in the render_invalid_data_errors` method.

These different error codes are helpful for control flow, as we have Javascript in the front end determine if the response was successful, and have our application perform different tasks depending on the error code of the response. For example, if the household creation was successful, I can set state with the details of the newly created household in React, or I could set state for front end error messages otherwise:

In the else statement, I set state for the errors, which is the array of error(s) returned from the server. I can then display these errors in an alert message to the user, letting them know exactly what wrong, and what to fix in the form data before continuing and being pushed to other areas of the application.

Many-to-Many Associations in Active Record Example

william-luck — Tue, 18 Oct 2022 17:49:25 +0000

Background

Using Ruby, Active Record, Sinatra, and a React frontend, I created a traveler tracker for travelers in a country at a given time. Users can scroll through a list of all countries, see the number of travelers in that country, select the country for a list of current travelers, and see the individual visits for the traveler in that country. Additionally, users can see the traveler profile, and there are options to add a new traveler or a new visit for an existing traveler:

The application makes use of three backend models, Country, Visit, and Traveler. A given country has many travelers, through the visits recorded in that country. Similarly, a traveler has many countries, through visits recorded in each of the countries they visited. Each visit belongs to both a country and a traveler (many-to-many association), and only one can traveler can stay at an an accommodation at a time (which is recorded as a visit):

class Country < ActiveRecord::Base

    has_many :visits
    has_many :travelers, through: :visits

class Traveler < ActiveRecord::Base 

    has_many :visits
    has_many :countries, through: :visits

class Visit < ActiveRecord::Base
    belongs_to :country
    belongs_to :traveler

Entity Relationship Diagram

When I was thinking of ideas for the relationships needed to build this application, I originally came up with this ERD:

The Visits are established correctly as the join table, but the Travelers has an unnecessary column as current_country_id, with no association to a country established other than the ID. However, each traveler will have a list of countries they have visited, and you could find the current country of a traveler by just calling #countries[-1] on an instance of a traveler, as such:

class Traveler < ActiveRecord::Base 

    has_many :visits
    has_many :countries, through: :visits

    def current_country
        self.countries[-1]
    end

'from_country_id' is a separate column, and this is used for nationality. I kept this an integer to correspond with the country IDs of the countries table, instead of having to match a nationality string exactly with the country name. We could just find a traveler's nationality by calling #find(#traveler.from_country_id) on an instance of a country. This leaves us with the following ERD:

Finding travelers currently in a country

While we could easily query which country a given traveler is currently in, it is a bit more difficult to find all the travelers that are currently in a given country. Calling #travelers on an instance of a country will return all the travelers that were in that country ever, through the series of visits belonging to each traveler in that country. Similarly, calling #visits on an instance of a country will return all the visits in that country ever, not necessarily the visits of the travelers currently in that country. We can use the #current_country method defined above to help with this.

As calling #travelers on an instance of a country returns all travelers in that country ever, we can iterate through that array of travelers to see if their last country_id corresponds with the country_id of the country instance. If this is the case, we can push those travelers to a new array, and return that array to get all the travelers currently in that country:

class Country < ActiveRecord::Base

    has_many :visits
    has_many :travelers, through: :visits

    def travelers_currently_in_country
        travelers_in_country = []
        all_travelers = self.travelers
        all_travelers.each do |traveler|
            current_country = traveler.current_country
            if current_country.id == self.id
                travelers_in_country << traveler
            end
        end
        travelers_in_country.uniq
    end

How is this used in the application controller?

When I click on a country in the application, we want the travelers in the country to display immediately below the list of countries. I have defined this route in the application controller for get requests to receive JSON of the travelers in a given country, using the above #travelers_currently_in_country method:

get '/travelers_in_country/:id' do
    selected_country = Country.find(params[:id])
    selected_country.travelers_currently_in_country.to_json
  end

We make use of the params hash here, so that the route is dynamic and accepts a country ID. The params hash is created when a request is made to that endpoint. As we are not sending any data in a post or patch request, the dynamic id is the only thing that we need to use with the params hash. We use Country.find(params[:id]) to find the matching country in the database, and then call the #travelers_currently_in_country method on that country.

In the frontend, the fetch request looks like this:

fetch(`http://localhost:9292/travelers_in_country/${selectedCountry}`)
            .then((r) => r.json())
            .then(travelersInCountry => setTravelersInCountry(travelersInCountry))

We pass the ID of the selected country in the url, the application receives the response from the API, and we set state to have the list of traveler's re-render in the frontend. We get an array of objects in this response, and we can then call .map to return JSX to display the travelers in that country.

Tutorial: communication between sibling components using state, and controlled forms

william-luck — Mon, 18 Jul 2022 23:06:29 +0000

Component hierarchy:

Parent Component: App.js
... Child component: ExampleForm.js
... Child component: SubmittedFormInfo.js

Goal

I have an example form in the child component ExampleForm to receive input on a name, image url, and a price for a new item. I want this information to immediately be displayed in another child component SubmittedFormInfo, without the need to refresh the page.

Both of these components are children of App, but information cannot be directly passed between sibling components such as these. How can we take the information from the form, and then immediately display that information in the other component?

Walkthrough

This issue depends on the use of state and setter functions passed down as props to each of the components. Since information cannot be directly passed between sibling components, we need to make use of state in the parent component, which will pass down information to each of the two components so that the data can be displayed.

App component
Begin by utilizing the useState hook in the App component, and use an initial value of an empty object, which will eventually contain the information from our example form:

function App() {

const [newItem, setNewItem] = useState({})

We are not too concerned with the actual value of newItem just yet. Instead, begin by passing down the setter function setNewItem to the ExampleForm component. The first goal here is that we want to change the value of newItem upon form submission using the setter function passed down:

<ExampleForm setNewItem={setNewItem}/>

function ExampleForm({ setNewItem }) {

ExampleForm component
Before going further, we need to use a controlled form to keep track of the data submitted by the user. For simplicity, declare three initial values as empty strings for each input field on the form using the useState hook:

function ExampleForm({ setNewItem }) {

  const [name, setName] = useState('')
  const [image, setImage] = useState('')
  const [price, setPrice] = useState('')

These will be used as values for each input in the example form, as follows:

<form>
    <input type="text" name="name" placeholder="Name" value={name} />
    <input type="text" name="image" placeholder="Image URL" value={image} />
    <input type="number" name="price" placeholder="Price" value={price} />
    <button type="submit">Add Item</button>
</form>

For controlled forms, every change that the user makes to the input field should update state to keep track on the information entered by the user. This is especially useful for immediately making use of the information, such as when you want matching items to display in the DOM using a search bar as the user types. Even though we only need this information upon submission, it is still helpful to use a controlled form. To make this form controlled, begin by declaring three separate functions to handle a change to each of the input fields. Within each function, we want to make use of the setName, setImage, and setPrice setter functions from the state in this component. Each function should update state using the event object, to access data on each letter entered to the form:

function handleNameChange(event) {
    setName(event.target.value)
  }

function handleImageChange(event) {
    setImage(event.target.value)
  }

function handlePriceChange(event) {
    setPrice(event.target.value)
  }

To call these functions when the user inputs data, use these functions as callbacks for onChange events in each of the form input fields:

<form>
    <input type="text" name="name" placeholder="Name" value={name} onChange={handleNameChange}/>
    <input type="text" name="image" placeholder="Image URL" value={image} onChange={handleImageChange}/>
    <input type="number" name="price" placeholder="Price" value={price} onChange={handlePriceChange}/>
    <button type="submit">Add Item</button></form>

The general idea is that as the user types, each of these functions will be called to update state. Since we are using state variables as the input values in the form, the form values will update as the state updates with the use of the handle functions. Once the user finishes typing, we will have complete information available to use in each of the name, image, and price state variables.

When the user submits the form, we want to change the value of newItem declared in App, using the information entered by the user. We can do this by calling the setter function setNewItem, which was passed down as a prop to the form component. Begin by declaring a handleSubmit function, which should be called when the user submits the form using onSubmit in the opening form tag. In the handleSubmit function, we want to create a new object, specifying key/value pairs using state variables as each value, as so:

const formData = {
      name: name,
      image: image,
      price: parseInt(price)
}

Then call setNewItem, using the formData object as the specified value:

setNewItem(formData)

Optionally, we can prevent a refresh of the page and set the form values back to empty strings to receive new data from the user. The final handleSubmit function should look something similar to this:

function handleSubmit(event) {
    event.preventDefault();

    const formData = {
      name: name,
      image: image,
      price: parseInt(price)
    }

    setNewItem(formData)

    setName('')
    setImage('')
    setPrice('')
 }

The primary line of code to focus on here is setNewItem(formData). This updates state in the parent App component, which allows us to then pass that form data to SubmittedFormInfo as a child of App.

SubmittedFormInfo component
To finally display the form data in our application, in the App component, pass down newItem as a prop to SubmittedFormInfo:

<SubmittedFormInfo newItem={newItem}/>

newItem now contains an object with the name, image url, and price of the item added by the user. Have SubmittedFormInfo receive the prop, and optionally destructure newItem to more easily use the information contained in the newItem object.

function SubmittedFormInfo({ newItem }) {

  const {name, image, price} = newItem

All that is left to do is display the name, image, and price variables in the DOM:

return (
    <header>
      <h2>
        Submitted Form Data
      </h2>
      <p>Name: {name}</p>
      <p>Image url: {image}</p>
      <p> Price: ${price}</p>
    </header>
  );
}

With this addition, once the user submits the form, the information entered by the user should now display automatically in the DOM. This occurs because of state updates. Since SubmittedFormInfo depends on the variable newItem in state, once the value of newItem updates, this will cause the SubmittedFormInfo component to re-render, immediately displaying the information entered by the user.

Conclusion

We used newItem and its setter function to update the application. We began by passing down 'setNewItem' to ExampleForm, which was called when the user submitted the form. As the user typed, state in the form component updated, keeping track of the values entered by the user. Upon submission, we set the value of newItem to the data entered by the user. This caused a state update for newItem, which was passed down to our display container as a prop. This component then re-rendered upon submission, displaying the information entered by the user immediately below the form, with no need to refresh the page.

Navigating the JavaScript Event Object

william-luck — Tue, 10 May 2022 19:28:50 +0000

Background:

I just completed phase 1 of Flatiron's Software Engineering Flex program (I was supposed to complete this phase a few weeks ago, but that's the beauty of the flex program). I created a single-page application to keep track of those harder-to-realize accomplishments. The main idea is quite simple: complete tasks, level up corresponding skills, and earn rewards. A task log is located underneath the primary game bar to keep track of tasks completed:

Most of this functionality was achieved with the help of event listeners, namely click, submit, and keydown. I relied heavily on the event object to manipulate the DOM and get my application moving the way I wanted it to.

What is the event object?

From my own understanding, the event object is an object created once you satisfy the condition of the event listener. This event object is automatically passed into callback function, and you can access multiple points of useful information through that event object.

In the callback function itself, define a parameter to receive the event object. The name of the parameter can be really be anything, but by convention and just for ease of use, it's typical to name this parameter "event", or just simply "e". When working with the event object, I find it helpful to just console log the event at the start to remind myself of what I can do with it:
document.addEventListener('click', e => console.log(e))

Viewing the console, you get a seemingly endless amount of properties, with nested objects under certain keys:

But of course, the event object generated by clicking on a random location on the page does not tell you much (well it does, but there's no information I'm concerned with at this point). Adding event listeners to specific elements on the page gives much more relevant information to play around with.

How I used the event object in my project

For my project, I was primarily concerned with the information in the event object under e.target. I was looking for the value of the ID attribute in the event object, which I defined in my HTML:

<button class='task-button' id="self-comp-1" >Took a break when I needed to</button><br/>
<button class='task-button' id="self-comp-2" >Used positive affirmations</button><br/>
<button class='task-button' id="pers-1">Had an 'aha!' moment </button><br/>
<button class='task-button' id="pers-2">All lab tests passing</button><br/>
<button class='task-button' id="gh-1">Coded along during a lesson</button><br/>
<button class='task-button' id="gh-2">Refactored code</button><br/>
<button class='task-button' id="supp-1">Received / gave support on Slack</button><br/>
<button class='task-button' id="supp-2">Paired with a technical coach</button><br/>

Using a for loop, I added a "click" event listener to each of eight task buttons on my application. In my callback function, I made use of a series of conditional statements to check the ID of the button that was clicked. If I click on the first button labeled "took a break when I needed to" e.target.id evaluates to "self-comp-1", and a series of functions will execute from that point to update the corresponding skill of self compassion:

for (const node of taskButtons) {
    node.addEventListener('click', e => {
        if ((e.target.id === 'self-comp-1') || (e.target.id === 'self-comp-2')) {
            if (selfCompPercentage < 100) {
                selfCompPercentage = updatePercentage(selfCompPercentageNode, selfCompPercentage, ' - Self Compassion');
                updateProgressBar(selfCompProgressBar, selfCompPercentage);
                addTaskCompleted(e);
            }

In the last line of the above code block, I passed the event object to another function, addTaskCompleted(e), which updates the task log at the bottom of the page. I needed to do this because I needed to list the text contained in the button that was clicked by the user, like so:

Using the same event object that was created when I clicked on the button, I first declared a variable completedTask to create an element to store the name of the task. And to use the event object passed into the function, I set the textContent of the completedTask to e.target.textContent, which corresponds with the text inside the button originally clicked. Lastly, I added the new element to a completedTasksContainer:

function addTaskCompleted(e) {

    const completedTask = document.createElement('p')
    completedTask.textContent = e.target.textContent;
    completedTasksContainer.appendChild(completedTask)

Also in the task log is an ability to add a comment, which also uses an event listener and a separate event object, as part of a 'submit' event. I created a form with a comment bar and a submit button, and then added an event listener upon submission of the simple form, with its own callback function:

// creates form next to the completed task
    const inputForm = document.createElement('form')
    inputForm.id = 'input-form'
    completedTask.appendChild(inputForm)

    // Adds comment bar
    const inputText = document.createElement('input')
    inputText.type = 'text'
    inputText.value = ''
    inputText.placeholder = 'Add comment..'
    inputText.id = 'comment'
    inputForm.appendChild(inputText)

    // Adds submit button 
    const submitButton = document.createElement('input')
    submitButton.type = 'submit'
    submitButton.name = 'submit'
    submitButton.value = 'Add'
    inputForm.appendChild(submitButton)

    // Adds comment to task completed upon submission of form
    inputForm.addEventListener('submit', addCommentToTask)

When adding the comment bar itself, the most important thing to note here is inputText.id = 'comment'. This allows me to access the text that was entered in the form in my callback function, once again with e.target, and add that text as a bullet point under the completed task:

function addCommentToTask(e) {

    e.preventDefault()

    const comment = e.target.comment.value
    const completedTask = e.target.parentNode  

    e.target.remove()

    const commentNode = document.createElement('ul')
    const commentText = document.createElement('li')
    commentNode.appendChild(commentText)

    commentText.textContent = `Comment: ${comment}`

    completedTask.appendChild(commentNode)
  }

A few things to note here:
e.preventDefault() prevents the page from refreshing upon submission of the form.
const comment = e.target.comment.value stores the value of the inputted text in a comment variable, using the ID of the comment bar itself.
const completedTask = e.target.parentNode saves a reference to the task completed, to use a header for an bullet point
e.target.remove() removes the comment bar and submit button from the task log.

After adding an unordered list bullet point, I set the text content of the bullet point to the comment variable with some string interpolation:

commentText.textContent = `Comment: ${comment}`

The third and final event object I worked with was one created by a 'keydown' event. Upon reaching 100% in a skill, a function is called to display an emoji award. I implemented a completely useless but fun feature that allows you to rotate the axe awarded to the user upon completion of the persistence skill. The axe can be rotated plus or minus 45 degrees, depending on whether the left or right arrow is pressed down. To do this, I added a 'keydown' listener to the window (not to the axe itself, because I want the user to be able to rotate the axe at all times if the user has last clicked on the window itself):

function displayAward(node) {
    rewardsTile.textContent = "Earned rewards:"

    if (node.id === 'self-comp-percentage') {
        addHeart();
    } else if (node.id === 'pers-percentage') {
        addAxe();
        window.addEventListener('keydown', rotateAxe)

For 'keydown' events, a different event object is created, which includes the key that was pressed down as a property. Similar to the way I console logged the event object in response to the 'click' event, console logging the event object here leads me toward some conditional logic to use:

Notice the key: and "ArrowLeft" property. Along with the event object automatically passed into the callback function, in which I use 'e' as a parameter in the callback function itself, I toyed with e.key to determine which direction the axe should rotate, using conditional logic:

function rotateAxe(e) {
    const axeNode = document.getElementById('axe')

    if (e.key === 'ArrowLeft') {
        axeRotation-=45
    } else if (e.key === 'ArrowRight') {
        axeRotation+=45
    }

    axeNode.style.transform = `rotate(${axeRotation}deg)`
}

Final Note

Event objects are confusing. When I was first introduced to this topic, I couldn't wrap my head around how an object was automatically created and passed into callback functions. How was it passed into the callback function if i didn't explicitly pass it in? Why call it 'e' or 'event'? What is all this information dump that I have to work with? What else can I use in e.target? These questions are okay, and to not have immediate answers to them is more than okay. I did learn a lot of technical mumbo jumbo through this mini-project, but most importantly, I learned to not be intimidated by the questions that lead to other questions.