Stretch

Introduction and Learning Goals

You’ve made it through your first front-end JavaScript framework: React! Now that you have the building blocks down, it’s time to take what you’ve learned, build something creative, and dive into some independent learning of new technologies.

Incorporating a new technology into your application that isn’t explicitly taught will give you the opportunity to differentiate yourself from other Turing grads and give you a great story to tell in your job interview - employers love to hear about your experiences being self driven and learning new technologies outside of the standard Turing curriculum.

No one hires a junior dev based on what the junior already knows. Instead, junior developers are successful when they showcase their ability to learn and ask questions. This project will provide tangible, demonstrable anecdotes for you to bring up during interviews to show your ability to struggle with new material and problem solve!

You have a lot of freedom with this project, but there are a few requirements listed next.

Requirements

By the time this project is submitted for evaluation, it must:

  1. Meet the specs listed below under “MVP”
  2. Use at least one external API
  3. Implement one of the “Stretch Technologies” listed below
  4. Be deployed
  5. Be a featured project on your resume (Your resume must meet all requirements listed in this document.)

MVP

Your application needs to be summarized with a minimum viable product. What is the smallest set of features to give the user a way to accomplish the goal of the application?

The functionality for Stretch will be MUCH LIGHTER than the functionality in previous projects. Remember: the learning goals of this project are to expand/deepen your understanding of your learning process & dynamics within a team - NOT to build the flashiest thing ever.

The project is very open-ended in that you can make pretty much anything you want. However, we have some requirements to follow:

  • Assume one single user - multiple users with log in and authentication is out of the scope of this project.
  • The application cannot simply be a display of data - there needs to be some way for the user to work with or manipulate the data (favoriting, searching, filtering, commenting, rating, etc)
  • The application should be a multi-page application using React Router
  • Be able to answer: What problems are you solving? What features must the solution include to solve this problem?

Create a summary (MVP) of what your application will do and who your application is made for - be specific with your audience because it will give you direction in your work and make your project more interesting.

Data APIs

expander arrow Here is a list of some data APIs that are open to the public:

Some of these APIs require API keys to consume the data. You’ll have to go to the documentation for that API to find out how to get an API key and how to use the API key in your network requests.

You can also take a look at this list of APIs for some more ideas. However, stay away from APIs listed here where “Auth” is “OAuth” and where “CORS” is either “Unknown” or “Yes”. If you find an API in this list or from somewhere else that you are interested in using, then let your project manager know so they can help you see if it will be relatively easy to work with.

Stretch Technologies

In addition to an API, you must choose a new technology (or set of technologies) to work with. Here are the possibilities for technologies you can explore for this project.

Note: For all technologies except for “Another Framework” listed below, the expectation is that you are using React.

expander arrow Global State Management

As apps begin to grow and grow, state management via this.state and passing props down through dozens of components gets kind of tangled, messy, and confusing. There are some tools invented to alleviate that issue:

  • React’s built-in Context API
  • Redux

Companies with large apps are likely to be using a state management tool like the ones listed above. If you’re interested in this, you should pick one tool from the list and use it within your React app.

expander arrow Workflow

Writing bug-free code can be made easier by adding some very common workflow tooling. Here are just a few you will see on the job, and learning these will make you productive in your job sooner. If you’re interested in this category, then you must complete all listed here:

  • Continuous Integration (using Travis CI or Github Actions)
  • Deployment to production using any depolyment service
  • Automatic deployment when a PR is merged to main on GitHub

expander arrow Testing

For those who just can’t get enough testing, you can challenge yourself to do acceptance testing with our friend Cypress, AND unit/integration testing with React-Testing-Library or Enzyme!

  • React-Testing-Library
  • Enzyme

If you choose this, then all of your large/important integration tests should be done with Cypress. Unit tests should still be done using React Testing Library.

expander arrow Another Framework

React might not be the framework you end up working with on the job, and employers might want to see that you can be flexible in the technologies/frameworks you work in. Choosing this category means that you would use a framework other than React - there are two you can choose from for this project since they have a similar feel to React:

  • Vue
  • Svelte

Some things to note: Instructors will not be able to give in-depth feedback because most instructors do not have a lot of experience in each of these frameworks, and you will still be required to test the application even though you are choosing a framework other than React. You will not be able to use React Router with these frameworks, start with a single-page application and add a routing tool once you get moving in the new framework.

expander arrow User Authentication

Some apps allow you to sign in using your Google, Facebook, or Twitter account - this is called user authentication. If you made this yourself, you will need a back-end server to store the user’s data and it gets complicated, which is too much for this project. Use a third-party library like:

  • Google’s Firebase
  • PassportJS
  • Auth0

to enable a user to login to your application via Google, Facebook, and/or Twitter. The user should be able to stay logged in even after refreshing the page.

expander arrow TypeScript

The JavaScript language that we know and love is loosely typed - meaning a variable that you make can hold a string, and then you can change the value to a number and JS has no problem with that. TypeScript says once a variable is a string, it must stay a string, amongst other features. It’s increasingly popular and some employers are seeking TypeScript experience.

You can add TypeScript in React! This is a big shift in writing JavaScript like you have been, so be sure to keep your MVP small and then you can add on as you go. To get started with TypeScript and create-react-app, start here.

expander arrow Building a Backend

Not feeling excited about any of the free data APIs? Build your own! If you choose this category, you would be responsible for building your own server in Express, connecting it to a PostgreSQL database (usually with Knex), and hosting it on some deployment service. You would not be required to use a separate data API.

expander arrow Progressive Web App

Progressive Web Application allow you to turn a regular web page into a native app with access to device hardware, push notifications, offline use, etc.

If you choose to create a PWA, your application must include:

  • a manifest file to be able to “install” the application and see an icon on your phone’s home screen
  • a service worker to make your app available offline (even if it doesn’t really function offline)

A few notes:

  • Beyond the requirements listed above, the rest of the technologies for PWAs are fairly complex (like web push, background sync, indexedDB). None of these should be included in your MVP.
  • The service worker that comes with Create React App can be really frustrating to work with. It is usually better to start from scratch, and there are various tutorials on how to create a service worker from scratch when working with CRA.

expander arrow Miscellaneous

If you choose from this category, then you must pick at least two of these options:

  • Styled Components
  • Localization and Internationalization (would recommend using a library for this like react-i18next)
  • GSAP Animations or WebGL Animations
  • 100% passing accessibility testing using an accessibility analyzer like A11y or Axe

Deliverables

Note: All of these dates are reflected in the calendar

Most Days

Your instructors will do a stand-up meeting in the mornings to see where the group is at, and give a chance for each group member to talk through what they’re working on or where they have blockers.

expander arrow Day 1 (3 PM MT)

expander arrow Day 2 (12 PM MT)

  • The link to your repo
  • The link to your DTR
  • The link to your Project Board
  • A link to 2-3 pieces of design inspiration that you will aim to mimic
  • A wireframe of your app - this can include sketches of your user interface, or a link to your Canva, InVision, etc. …in this google sheet

expander arrow Day 3

  • In a DM with both instructors, send us the link to a recent PR
  • Choose a PR that is related to your Stretch Tech, and use the PR description to fill us in on your learning.
  • Sometime in the next few days, we’ll perform a code review
  • You do not need to wait for our review to merge it in.

expander arrow Day 5 (during stand ups)

Your instructors will do a formal check-in with your group. At this check-in, instructors expect to see:

  • A very quick demo of your application so far detailing the progress made toward your MVP
  • Your testing suite running
  • Progress you’ve made on your Stretch Technology category
  • Any blockers you’re experiencing
  • Your plan going forward for the next few days

expander arrow Day 6 (9:30 AM MT)

Share your app progress with the class for Show and Tell! Be prepared to tell the story of what your app is, why you’re making it, and share a quick demo of your app so far. In total, the show and tell for your app should last no longer than 10 minutes (shoot for 5 minutes).

Your project does not need to be done or impressive by this point; this is more of a way to give you a milestone to shoot for and to help plan your timeline.

Demo Comp

One of the Stretch Tech projects will be entered into Demo Comp next inning! Demo Comp is an event that happens on Tuesday of week 1 where the top projects at Turing are presented by students in front of Turing students, staff, and real world devs. It’s an amazing opportunity to get your name out there and network. It’s a big honor and we’re excited to choose one of your groups to go represent your cohort!

Your instructors will choose our Demo Comp project by looking for the following things:

  • A polished application that is intuitive and professional
  • A bug-free application that meets all of the features from your MVP
  • Strong implementation of the stretch technology with best practices implemented in React, Router, and Cypress

Involvement in Demo Comp is totally optional.

Evals

Connecting back to the purpose of this project, Evals will be conducted in a way that gives you an opportunity to practice speaking about your learning experience.

Evals are

  • 1:1 sessions with you and an instructor from the Frontend Team
  • 15 minutes
  • Two interview questions - one technical (about your stretch tech) and one behavioral (you get to choose the “theme”, but not the specific question)
  • You will be expected to send your interviewer your resume prior to the interview via slack

Rubric

There will be no written feedback for this project, but each and every one of you is capable of self-assessing whether or not your project is proficient. Mentors and Rocks are also a valuable resource here. A Proficient project would include the following:

Professionalism/Workflow:

  • README concisely communicates the team’s individual and joint learning goals, the evolution of the project, and team member reflections while using good formatting to enhance readability
  • README links to all user GitHub profiles and any applicable repos/deployed sites
  • Setup instructions for any and all repos are thorough and verbose enough that even non-technical people (like recruiters) could follow them
  • Git commits are atomic, with concise and precise descriptions of the change made
  • PRs have full, consistent descriptions
  • Team members conduct consistent code reviews of PRs
  • Evolution of the project (decisions made, etc) is documented in the git history and PRs
  • When the project is run locally, the terminal shows no errors and no warnings

React Architecture:

  • A consistent, modular file structure is used
  • A clear understanding of class components vs function components is demonstrated
  • Only the data that a child component needs is passed down as props
  • Logic is kept out of return statements; return statements are as readable as possible, only communicating what will be displayed
  • The data displayed on the frontend is consistent with the data stored on the backend
  • Functions follow the single responsibility principle and are written to be reusable when appropriate
  • Data fetched from API is cleaned before being set to state
  • All components which receive props implement prop typechecking (proptypes or otherwise)

Stretch Technology:

  • Project implements the chosen stretch tech throughout the entire application
  • Group members can all individually speak about the stretch tech’s best practices and attempts were made to follow those best practices in your application
  • Group members have reflected on the process of learning these technologies and can speak clearly about their learning processes

Testing:

  • All user flows are tested
  • Async functionality is stubbed at least once
  • Tests make specific assertions about the content DOM elements contain

Lesson Search Results

Showing top 10 results