Structural Considerations:

This was my first project using ReactJS and Redux. Redux allows for what they call a “unidirectional” flow of data. The concept is simple enough, but actually seeing how the flow of data travels through the application took a while for me to understand. Also, the set-up is a lot to process the first time through, but the benefits are immense once you get it working. When using an MVC framework like Backbone, every time you make a change to the model, you also have to re-render the view which can get complicated as your app grows and gets complicated. But, ReactJS takes care of all rendering of the view for you, and Redux keeps track of all changes in the state of your app.

Thought Process:

The user has a dashboard that displays all their saved jobs which they can then click on to get to an individual job view page. We thought this would be a logical place to delete a job because you might read the details of a saved job and decide that it really wasn’t what you were looking for.

Before typing any code, I made a mental list of all the places that would be impacted by this button, which looked a little like this:

Create a delete button component

Import button into the job view container

Create a method that initialized the process of deleting a job from the database in the Job View Container

All of my initial thoughts were mostly about the front-end. It also made me realize that I had some questions about how properties and elements were passed between components and containers in React. Before I started coding, I researched some example projects online, as well as other parts of the app that other members of my team had worked on. I was then able to create a button in the job view container, as well as a skeleton for a handle-delete method that would be called when the button was clicked. At this point, I had to go back into research mode to try to figure out how Redux would help us make the change to the database as well as communicate with the React components of our app to actually delete the job from our view.

Redux:

I love Redux, and I highly recommend getting started with it by watching the series of videos on Egghead.io by its creator Dan Abramov which you can find here.

At the heart of Redux is a single STORE which is basically an object that keeps track of the entire state of your application. That store can be modified with specific actions which are then put into play using a reducer.

Actions are simply all of those things that need to happen to make your app work. In our project’s case, we have actions that add users to the database, add jobs, refresh the database, etc. Reducers….reduce (if you need a refresher on what reduce does, checkout my Re: contains post). In terms of Redux, a reducer takes an ACTION and applies it to the PREVIOUS STATE and reduces it to get a new state.

This is such a simple concept, but putting it into play when implementing the “Delete Jobs” feature from start to finish is finally how I was able to put this into practice.

In terms of my thought process, before I wrote my code I wrote comments and pseudo code in every file I had to touch to make this successful. This included our reducer file, actions file, and action types files. I hope to explain exactly what I did in the code in my next post.

In my current project, I am in charge of getting our Rethinkdb database up and running. Not only am I new to Rethinkdb and Thinky.io (the ORM library we are using) but we are also using Koa as the server. Koa is similar to Express in that it simplifies setting up a server in Node, the major difference being that it relies on function generators. All of these things would make great blog posts themselves, but I wanted to focus on how I’ve finally been able to leverage the power of Postman to help my code. (You can read my original thoughts on Postman here). The following post illustrates how I was able to use Postman to test out POST and DELETE requests to make sure data was getting to our database.

Routes

Before starting, I checked my code to make sure it was free of errors. Then, I started my server and database. This may be an obvious step to many people, but when I first started coding, I literally would forget to do this every time. Rethink has a really nifty web interface when you run it in the browser which you will catch a glimpse of later.

In our server.js file, these are the two routes I decided to test out using Postman.

POST

This is what my addUser function looks like – note that it uses a function generator, which you can easily spot since it uses an asterisk. Since this was my first time using one, I decided it would be a great time to use Postman to see if I could actually get data posted to my database.

I’m using mock data here and passing it directly into my User model. Before saving the user, it queries the table to see if there is already an existing user, and if there is it throws an error. If not, it saves the new user to the database!

Postman mimics what your program will do when it passes data around, and the great thing is that you can use it before you have all parts of your app complete. After running this POST request in Postman, I was able to query the database and see that the user did in fact make it in.

Rethink allows you to query your database in the browser window. Here I double checked to make sure my test user made it into my ‘User’ table, which it did!

To make sure I could not add a duplicate user, I tried adding the same user to the database using Postman to do the same post request. In the photo below, you can see how Postman works to do these types of requests. You can see the url in this case is made up of localhost and port 3000, which is where my server is running from, as well as the user route (/api/user). You choose what kind of request you want, put in the url, and press send – super easy! In this case, it responded with “Email already taken!”, just like I wrote in my addUser function.

DELETE Success and Other Info

I tested out deleting a user by following the same steps as I did for the POST request, and it was successful! I confirmed with the database that I no longer had any entries in my User table. This image is just to show what a nice interface Postman has, and all the different requests you can make. I didn’t use it this time, but you can see a “Params” button where you can add specific parameters to your request. This is great when testing out authentication because you can pass tokens into the request.

Look at all the different types of requests you can make in Postman: GET, POST, PUT, PATCH, DELETE….and many others I haven’t gotten a chance to use yet.

Steps to using Postman*

Double check your routes and functions before you try to use Postman to make sure they are doing what you want them to do

**You will see different results depending on what kind of call you make. Sometimes the information is really clear, but sometimes it isn’t. After deleting the user from the database, I thought my response was an error, but it actually wasn’t. So…be careful.

Bugs and Looking Forward

At this point, at least I know that the connection to my database is solid and that I am making queries using the correct syntax. However, right now I have just been passing around mock data. My next step will be connecting it to actual user data coming in from the client-side of the app. I also need to get a better grasp of how data is passed around in Koa. Since I am working on a team, my next actual step is to check-in with everyone at our daily meeting tomorrow to discuss next steps. I can’t wait!

VIEW ONLY

Model-view-controller (MVC) is a software architectural pattern. Different frameworks, like BackboneJS for instance, started popping up to help software developers architect web applications that kept the logic of the view of the page separate from model it was displaying and how it was actually getting displayed on the page via the controller. This helps keeps your code organized and logical – otherwise, your code might start getting….spaghetti’ed….i.e. – really tangled up and confusing.

React has gotten a lot of attention in the past few months, but it’s important to realize that React, only helps you take care of the view. As a programmer, you get to make decisions about how to structure the rest of your technology stack.

JSX Intro

JSX is html-like and awesome in my opinion! According to the React documentation itself, “JSX lets you create Javascript objects using HTML-syntax.” JSX is not requiredwhen using React, however it is commonly used and pretty simple once you get accustomed to the syntax. React helps you separate concerns in your code, so components will help you isolate exactly one part of the DOM that you need to update.

Tips:

1. {/* COMMENT HERE */} - This is the syntax you use if you need to make a comment in your JSX. The normal ways you would comment in JS, such as // or /* */ will not work.

2. Wrap new components in a div or span tag. If you don’t, they won’t get properly converted and placed to the DOM correctly.

3. return ( ); – React components return the part of the DOM you specify with the JSX. All of the JSX, or pseudo-HTML as I like to think of it, gets returned inside of two parentheses.

React has taken a period of adjusting to the way it works, but I hope to use it more for future projects.

File path shortcuts are commonly used in coding. Here is an example from a file where I was configuring authentication using passport:

In order to finish this feature of my site, I needed to use information from two other files, which I required on lines 4 and 5. I used to get confused about what one dot (.) vs. two dots (..) meant, but it’s actually very straight forward!

. means the file is on the same path level as the current file. Line 5 of my code uses this because I’m requiring the file auth.js, which is in the same directory as the current file passport.js... means the file is one path level up. Line 4 of my code uses this because the user.js file it needs is in the models directory, which is one level up from passport.js.

This type of path syntax is called a “relative path” because the path in question is being written in a way that tells its relationship to the path in question. You have to be careful if your file structures changes because then the paths will no longer work!

Sometimes when someone suggests a useful tool or library for me to use, it takes awhile for me to find the exact moment where that tool would be useful. I had heard about Postman a few times – for instance, during our major assessment it was even suggested as a tool to use for one of the prompts, but I couldn’t figure out how it could be useful in that situation.

The Situation

During our last project, my task was to figure out a few ways that we could extend the API that the project we inherited was using to locate and place markers on a map (the trailapi can be found here). While I was able to view information coming in from the API in the console, it wasn’t until my teammate told me that this would be a great place to Postman that I even considered the tool.

Eventually I reached a point where it become difficult to figure out how I could gather and manipulate the data coming in from the API because of how it was stored in nested objects. The way I was attempted to target certain properties was not working, and so I turned to Postman.

Trail and Error

I ended up pasting the example url from the API to see what I was actually getting from back from a GET request. Turns out I was getting an empty places array! The data in the url was just from the examples the API gave so users would know how to string the url parameters together. I felt silly that I didn’t realize that sooner.

I eventually figured out how to target trail descriptions and directions in the API so we could display them on the page.

Other Uses

Postman is powerful if you know how to use it. You can do practically any type of request (GET, POST, DELETE, PUT, OPTIONS). Additionally, you can test out different types of authorization, and send information in the headers to test out tokens or sessions. I look forward to finding other ways to use it as I move forward into new projects.

Last summer, I went to a Girl Develop It NYC panel where 6 women developers shared their experiences about how they got into the tech field and about what their day-to-day life was like. One of them said that the biggest lesson she learned was how to know what question to google when debugging her problem on the internet.

This is still something that I’m learning. Sometimes when I hit a wall when I’m coding, I can only see the problem from one point of view.

Example from Group Work

For a group project, my team and I created a Stack Overflow clone (http://stackoverflow.com/) which is a question and answer forum for developers. Our idea was to create a similar website, but only for people in the Hack Reactor Remote Community since we noticed that a lot of great resources and information were getting lost in our group messaging app. We’re proud of how it turned out (you can read my teammate’s write up o
f it here)!

When we planned out our scope of work, I was put in charge of researching how to use GitHub to authenticate users when they logged onto the website. I researched and I found that Passport was a common module people use to help them with authentication (http://passportjs.org/). I set out to explore how it worked and to understand it. I was able to make a small application that used passport to login users. However, when I tried to connect it to my group’s larger and more complicated app, I was lost. Try as I might, I could not get it to work.

The Perspective I was Missing

I spent a lot of time researching how to authenticate using GitHub, however, I failed to take into account other technologies in our stack and how they influenced what was happening to my code. Sometimes when I’m feeling frustrated with a bug, I tend to take it personally. This time, I became frustrated with myself for a day or so because I couldn’t figure out how to make it work.

With the idea of research in mind, the question I was not asking had to do with how Angular (the front-end framework we used) could make authentication challenging. Turns out, other people at one point or another had this problem as well, and developed tools to solve it. The great thing about open source software is that people develop and share specific tools to use to help solve problems. One of these tools ended up being the answer to our authentication problem.

Benefits of Teamwork

Even though I was not able to get Passport to work, I was able to document my code clearly and explain my thinking to my teammates. One of them took my code to try to make it work and was running into the same issues as I was. However, he researched authentication with Github AND Angular on the internet, and ended up finding Satellizer (https://github.com/sahat/satellizer). We ended up being able to use this tool to successfully fix our authentication issues.

Lessons Learned When Truly Stuck

Talk out the problem with a teammate – they might know something you don’t, or they might be able to see the problem from a different perspective

Think about how the entire tech stack you’re using could be influencing your bug

Move onto something else and come back to the problem later

Keep at it – be resilient in the face of a problem. Programming is all about keeping a cool head and problem-solving.