- Make sure that you have Node.js v8.15.1 and npm v5 or above installed.
- Clone this repo using
git clone https://github.com/chasekaylee/possible-weather.git <YOUR_PROJECT_NAME>
- Move to the appropriate directory:
cd <YOUR_PROJECT_NAME>
. - Run
npm install
in order to install dependencieso.
At this point you can runnpm start
to see the example app athttp://localhost:3000
. - Run
npm start
and see the app running locally athttp://localhost:3000
.
- Ability to look up weather by location (supports city, state, zip, country, etc)
- Displays the weather forecast based on current location
- Toggle live updates (5 second intervals)
- Toggle units of measurement
- 82.16% Testing code coverage
This project was written in React and was bootstraped using React-Boilerplate. The work was distributed throughout the weekend and time spent developing was ~6 hours (had some fun so wanted to work a little longer). Although the app is complete there are some things on the top of my head I would like to improve. The following list shows some of the things on the top of my mind that are left to improve.
- 100% code coverage
- Add proper loading placeholder (vs content disppearing)
- Add adequate error handling based on API error edge cases
- Improve client/API response structure (established error codes)
- Clean up containers + component code
- Cache responses to limit API request to third parties?
- GraphQL? :O
The design I chose was based on the container/component architecture introduced by Dan Abramov years ago. This architecture has proven very reliable to me in production which is why I choose to use it for this project. With React hooks / React evolving as a whole this architecture paradigm is evolving, however, I still find it useful to use. This project is production ready and is structure to scale (both developer and client facing). The use of codesplitting and async load of resources allows the app to be highly performant as well. This is better demonstrated on applications of higher size and complexity.
I chose to put all my business / stateful logic in my containers and manage all my async side effects in the Redux Sagas. This method helps me organize my code in a structure that is both robust and intutive to me. I choose to also create a simple backend to proxy the API requests to the third parties to hide my API keys. Having my own backend also gives me flexibily to format the responses to my choosing.