Elvis Ibarra's Lambda School Labs Development Journal

I am a full-stack developer currently studying at Lambda School.

Checkout my personal blog where I recap the Lambda School experience from week 1 and my projects page at:

www.elvisibarra.com

Currently based in Los Angeles, CA

©2019 Elvis Ibarra - Made with DatoCMS

Labs Week 2

Connecting the Frontend/Backend

This week we worked hard to make sure that all of our backend routes were all working as intended and started to implement functionality such that frontend actions would start corresponding with backend responses.

Day 1

We started with the weekly MVP goals in mind: Get our authentication, configure our API (Stripe) & connect the deployed frontend and backend. We split into 2 groups and my group began to tackle Firebase authentication. We also had a quick meeting in the morning with the client to check on our progress and plan for the week.

Front End Pull Requests

Back End Pull Requests

We were able to successfully setup Firebase, a login component and then have a route where our user would receive and verify the token that they received upon login from Firebase.

Day 2

This was a very busy day where we finished writing all of our backend routes and began to implement React Hooks to manage state on some components. We spent a good amount of time talking about the best way to write some of our more complicated database calls. Multiple calls to the database? A call with multiple join statements? What if the data doesn't come back the way we want? Do we write our own reducer function? We figured out how to get exercises to come along with workouts but were unsure how to get our user model done without multiple database calls. We put in a request for assistance ticket (RFA) at the end of this day to speak with a Lambda School database expert so we could get a second opinion on our current implementation.

Front End Pull Requests

Back End Pull Requests

For our first pull request we setup our firebase login to take advantage of React's new Hooks feature. We changed our top level App.js to be a functional component and used setState to initialize the user and then dispatched an action to login which would update the state with the logged in user.

Here is what our code for that looks like:

**Top Level App Functional Component **

const App = props => {
  const initialState = {
    user: {}
  };


 class App extends Component {    const reducer = (state, action) => {
  constructor() {       switch (action.type) {
    super();          case "userModel":
    this.state = {          return { ...state, user: action.payload };
      user: userData          default:
    };          // A reducer must always return a valid state.
  }         // Alternatively you can throw an error if an invalid action is dispatched.
        return state;
    }
  };

   const [state, dispatch] = useReducer(reducer, initialState);

Login Functional Component

const Login = props => {
  const [email, setEmail] = useState("");     const [email, setEmail] = useState("");
@@ -19,19 +19,28 @@ const Login = props => {
        res.user            res.user
          .getIdToken()           .getIdToken()
          .then(idToken => {              .then(idToken => {
              console.log(idToken);             console.log(idToken);
              axios.post('http://localhost:9001/auth/user', {idToken})              window.localStorage.setItem("login_token", idToken);
                .then(res => {              axios
                  console.log(res)                .post(
                })                  "http://localhost:9001/auth/login",
                .catch(err => {                 {},
                  console.log(err)                  { headers: { Authorization: idToken } }
                });               )
            }                 .then(res => {
          )                 console.log(res.data);
                props.dispatch({ type: "userModel", payload: res.data });
                props.history.push("/schedule");
              })
              .catch(err => {
                console.log(err);
              });
          })
          .catch(err => console.log(err));            .catch(err => console.log(err));
      })          })
      .catch((error) => {console.log(error.code, error.message)});        .catch(error => {
        console.log(error.code, error.message);
      });
  };      
    };

We then finished up some backend routes and wrote a reducer function to make our workout route work and this is when we started to debate our user route effectiveness and put in a RFA since our join methods weren't working out as expected.

We also recorded our first whiteboard challenge on this day.

Whiteboard Challenge #1:

https://youtu.be/djPWT3sd0Sw

I got a fairly simple problem but was nervous having never done this type of problem in this kind of environment.

The problem itself wasn't too bad. I was given an array of names and had to write a function that would determine the winner of an election and if there was a tie the winner was the person whose name was last alphabetically.

I ran out of time to complete it but I was able to write a partial solution, albeit inneficient in pseudocode. I started to push unique names to their own arrays which I was going to check the lengths of & compare at the end. Once I saw the solution (use an object with key/value pairs to keep a tally of votes in the array) I realized how much nicer that was but was happy that I was able to talk through my thought process and approach.

I was definitely a bit nervous but now that it's over I know what I need to improve and how much practice I need.

Day 3

I woke up this morning ready to write the best join statement ever. I hacked away at it for a bit but I was not getting the desired response. Our RFA was quickly responded to however that same morning and we were quickly in a meeting with one of Lambda's best database experts. It was a great conversation. We learned and considered some options we had not thought of before but our biggest takeaway was that we should make it work first and foremeost and then worry about performance or making the code cleaner. We went with our multiple database calls solution that we had already implemented and moved forward. We spent the rest of the day working on the frontend and testing all of our routes so that we could be ready for out weekly check in with the client on the following day.

Front End Pull Requests

For the first pull request while my teammates were working on some frontend sytling I was working on refactoring the user endpoint based on our meeting with the database expert and our PM.

In the second pull request we refactored our endpoints as necessary based on our testing and got some more styling done. I was able to get all of our endpoints tested using Insomnia which helped me organize everything into folders. I signed up for the premium free trial to share my work with the team. It's pretty awesome. Once it was all working Chris checked for PostrgreSQL errors we got after deploying and then we were set for our demo the following day.

Day 4

After working all morning to style and make sure that our frontend and backend deployments were communicating and all was good for the demo it was time to meet with the client. We had a great meeting! He was very impressed with our progress and is looking forward to using our app when we finish. After lunch we started to work on getting our app fully functional. I'm learning so much every single day, it's awesome.

Front End Pull Requests

Here Matt and I tried to implement a dropdown menu using React Hooks and added some styling to the Workout View page to begin the functionality here. It's still a work in progress but it's nice to start implementing the vision on the frontend as well.

Here's recap of the week! (not including Friday). A great, productive week. We hit our MVP early and worked to get 3's on our review by the end of the week. I really appreciate my team for being so open with each other and willing to teach and be taught. We work really well together and communicate very effectively. I think a big part of that is that we are always working together in at least a pair of 2. Even if you are working on a solo mission it's nice to be able to reach out for help at any time and know that some is there along for the ride.

Next week we plan on being fully functional and responsive 🔥

The frontend is deployed to: https://flexlog.app/

The backend is deployed to: https://fitmetrix.herokuapp.com/alive

Interested in my experience at Lambda School before labs? Checkout: https://elvisibarra.com/lambdablog.html