Live site can be found here: TitanStar Rune Mastery
Public development Trello board available here
This application has been architected for future expansion as well as stability. An Outside in TDD approach was used for the whole development cycle, which includes both e2e tests using cypress and unit tests using test-library. The app simulates communicating with a backend API via functions stubbed with Promises to return mock data.
Trello was used to track all new features, as well as tracking future improvements and bugs encountered. The board contains a number of future features for the application that may still be implemented.
The application was started with CI and automated deployment in mind from the start. Github actions has been used as a test runner on PR requests, and merges into master. A strict feature based branching strategy was used, along with thorough testing practices. Linting and auto-formatting with prettier were set up to ensure code consistency and clean, legible code.
CodeClimate was hooked up for code analysis to grade maintainability and code coverage, and to help identify areas of the application which are in need of refactoring. Coveralls has been used to display the test reports generated by Jest, as well as create notifications of when code coverage decreases or is impacted by opened PR's.
The primary data structure chosen was a tree structure for maximum future flexibility. While the example given was a linear talent tree, talent trees are commonly branched. A tree for the core data structure will allow multiple children of a talent node to be rendered with a little refactoring. This had the side effect of utilizing a recursive rendering pattern for tree nodes components, which was a first time for me. I am familiar with recursiive functions, but never had a chance to work with recursive functional components.
Redux was chosen as the state library due to its high scalability, ease of testing, clear separation of concerns, and robust developer tooling. Due to the complex nature of tree structures, the data was normalized for storage in the redux store, and denormalized when being worked with. This also had the added benefit of making updates to nodes in the tree simple and efficient.
Due to similar complexity concerns, memoized selectors using reselect were used to access the state, and for counting talent points, which are derived from the state rather than being stored in it. Selectors, being composable from simpler atomic units, allowed for easy refactoring when state names were changed, which occured a few times over the project, and simply involved changing a line of code.
The redux state was tested with a wide integration strategy. The entire module was tested at once. The reducer was tested with the actions, and selectors used to select data from the state for asserting. A redux "duck" approach was used to organize redux, cohabiting all related feature code into a single module folder.
The requirements for the project on mobile had to be modified, as mobile devices do not have a right ouse button, rendering the mobile experience quite bad. Thus as an alternative a talent can be removed via a double click as welll as a right mouse click on both desktop and mobile.
There are a few larger gaps in the application as it stands. There is a lack of proper inline documentation utilizing a strategy such as JSDocs. The application has also not been optimized for accessibility. Finally, there is no UX around error handling (yet), though it is the most immediate feature to follow.
This project was bootstrapped with Create React App.
In the project directory, you can run:
Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
Launches the test runner in the interactive watch mode.
See the section about running tests for more information.
Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
See the section about deployment for more information.
Note: this is a one-way operation. Once you eject, you can’t go back!
If you aren’t satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.
Instead, it will copy all the configuration files and the transitive dependencies (webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you’re on your own.
You don’t have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. However we understand that this tool wouldn’t be useful if you couldn’t customize it when you are ready for it.
You can learn more in the Create React App documentation.
To learn React, check out the React documentation.
This section has moved here: https://facebook.github.io/create-react-app/docs/code-splitting
This section has moved here: https://facebook.github.io/create-react-app/docs/analyzing-the-bundle-size
This section has moved here: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app
This section has moved here: https://facebook.github.io/create-react-app/docs/advanced-configuration
This section has moved here: https://facebook.github.io/create-react-app/docs/deployment