1.P: Frontend App
Last updated
Last updated
Build an Application that solves a problem you have using React, HTML and CSS. We will not be able to persist data in database until Module 2, but there are still many useful apps we can build. If you want to try to create an Application with a rudimentary database please look at HTML's where we can manage JSON within our React Application.
This project must be a Frontend React Application that utilises React, HTML and CSS.
Complexity:
Application has at least 2 levels of components eg: App component and 1 or more child components
Application demonstrates the capability to lift up state
Application is organised as well as structured, it follows practices of component separation and has a good folder structure
The code is easy to comprehend and read
The Application contains meaningful variable and function names
Application contains components that can be reused
The Application preforms well without unwarranted rendering
The Application's code follows consistent coding conventions, regarding indentations and formatting
Git repository contains commits for each feature with descriptive commit messages
Application contains a README with the applications description, user stories and low-fidelity wireframes
The README contains instructions on how to run the Application
The best ideas are ones that solve our own problems. Since we cannot persist data until Module 2, consider apps that do not require us to store data beyond the current session. For example: games, calculators, guitar tuners, colour matchers, visualisers. Games may be the most engaging to implement because they typically require more logic. Consult your section leader if you are struggling to decide on an idea.
You will have roughly 4 course days to implement and complete this project. We will observe the following timeline to keep us on track.
1
Ideation phase 1
Post project ideas in Slack for feedback
SL to review ideas and share feedback
2
Ideation phase 2 Create planning docs: user stories, wireframes, kanban board
SL to review planning docs and share feedback
3
Start implementation
-
4
-
-
5
MVP deadline Users can complete the primary user story
SL to review code in GitHub, share feedback
6
Feature freeze
No new features, focus on polishing existing features and code to be presentable
SL to review progress and share post-feature-freeze suggestions
7
Project presentations
8
-
Rocket recommends the following project management strategies and tools for all projects.
Example user stories for Project 1:
An interior designer wants to determine whether 2 or more colours match and what an optimal colour palette might be for given a base colour
A daily commuter wishes to play Flappy Bird during his 30-minute commute
A couple wishes to play a game of checkers against each other on their shared computer
Above user stories may not require persisting user data beyond the current session. From Project 2 onward we will learn how to persist user data for multiple users accessing our apps at multiple times on different devices.
Each task on your board should take no more than 1 day to complete. If you think it will take longer than 1 day, break it down into smaller tasks. This will help you stay motivated and track progress more accurately. Move in-progress tasks to the Doing lists and completed tasks to Done.
Submit a pull request to Rocket's Project 1 repo
Add your Project 1 repo link to the Rocket Bootcamp Projects spreadsheet in your batch-specific sheet shared by your SL.
Leave sufficient time to polish your app to be presentable. Fewer, more-polished features are generally better than more, less-polished features. Below is a sample checklist to run through.
Are there obvious bugs?
Are variable names concise and precise?
Is each function sufficiently small and modular to be easily readable?
Is the visual design clean?
Is the app layout responsive?
Did we update the app favicon and page title?
Did we populate the README?
The Application follows the correct naming, casing and commenting
Application has been deployed with
Practise to others. Other batches will join and we will celebrate each others' hard work.
SL to review code in GitHub, share feedback in 30-minute
Demo video Record a for employers and the public, embed in README
Start with user stories. Who is our user and what is their ? Be as specific as possible. After we articulate user stories we can proceed to design our app.
After user stories, create simple wireframes to visually describe how users accomplish user stories with our app. Connect wireframes to form for each user story. Only include what is needed to accomplish user stories, no more and no less. Rocket recommends , a relatively simple and popular design tool.
is an introduction to wireframing with Figma. Rocket recommends only low-fidelity wireframes for our projects due to limited time. Below are example wireframes by Figma; we can create user flows by navigating to the Prototype tab in the right sidebar and adding connections between wireframes.
After user stories and wireframes, Rocket recommends using a to track implementation progress. A kanban board is a progress-tracking board that contains broadly 3 lists of tasks: To Do, Doing and Done. Rocket recommends for its simplicity, and the for its relevance to SWE.
Start by forking that contains an empty Vitejs app. This will make it easier for SLs to review your code by allowing us to submit projects via pull requests.
If you would like to deploy your app to the internet, follow Vitejs GitHub Pages this should be familiar as we are already using GitHub for code hosting.
Rocket recommends designing and building the mobile version of your project before the desktop version. It will be easier to add features to a UI for the desktop version than to remove features from a UI for the mobile version. Use Chrome DevTools to .
Do we have above major functions and inline comments above code that could be confusing to others?