Onespot Dashboard
Build
Using webpack to build the project. A lot of the build configuration is based on - https://github.com/davezuko/react-redux-starter-kit
Continuous Integration/Deployment
We use CircleCI to build the onespot dashboard. The build does the following steps
- Lint the src files using ESLint
- Run the flow type checker to check for any type errors
- Run the tests
- Build the project (bundle, uglify)
- On green build, if we are on the master branch, upload the build artifacts to a versioned folder on S3
- On green build, auto deploy the latest code to http://staging.dashboard.onespot.com
The build artifacts are uploaded to s3://onespot-dashboard/lib/builds/${version}/ where ${version} is the following - ${package.json version number}-${circleci build number}
The version number is also set in the code as part of the build process, and we make it available as a parameter on the window object. To check the version number from the website, open the console and log out '_DASHBOARD_VERSION_'. This version number also includes the git hash of the build.
Deployment
The site is served from an S3 bucket configured to serve a website.
Because we are not using hash history we need to add a rewrite rule to the s3 bucket. See this stackoverflow question detailing the rules that need to be added: http://stackoverflow.com/questions/16267339/s3-static-website-hosting-route-all-paths-to-index-html
Current staging server at http://staging.dashboard.onespot.com/
To deploy to the demo server, call the 'deploy-to-demo.sh' script in the project root, passing in the version number you wish to deploy e.g.:
./deploy-to-demo.sh 1.0.0-65
The script just copies the artifacts from the s3://onespot-dashboard/lib/builds/ folder to the demo s3 bucket
Deploying in progress code
If want to deploy some in progress code that is not merged in to master, you can use the 'npm run deploy:staging' command to build and push the current code you are working on to http://onespot-dashboard-staging.s3-website-us-east-1.amazonaws.com/ This is a separate bucket that we can use for this purpose.
CSS
Currently uses CSS modules - https://github.com/css-modules/css-modules and some inline styling. CSS modules is probably a better approach but material-ui uses inline styles so there are some cases where we have to use them. Adding support for css modules is on their roadmap, so we may be able to clean this up in time.
Dataloading
The app consists of two types of components -
- Container components - wired up to selected global state by redux, handle data fetching, state updates
- Presentional components - concerned with how things look, get their properties passed in to them, not aware of redux
Data loading for the container components (bubblegraph, location map, time line, posts, visitors etc) is handled in the same way -
- Update the atom to indicate that we are making an api request for the component - the UI can then show a loading icon in this case
- When the api call completes parse the response and set it on the global atom under the components key
- Clear the loading indictor in the atom
The only thing that changes between the different component requests is
- How the state maps to the api url
- How the response should be parsed
There is a convenience method to create the data loading methods, which take the component key, a function to map the state to a url, and a function to parse the response.
See - (src/data-loading/data-loader.js) for the implementation.
Testing
Currently using mocha, chai and sinon for mocking and stubbing. Tests currently run in node, we need to add some tests that run in the browser.
Integration testing Looking at karma with phantom js