This is my personal starter for SPA development. It's a bare bones starter meant to be hacked. Perhaps in the future I will provide branches/forks/whatever for more full-featured applications based on this starter.
Ideally, this will end up being a generator or some kind -either through something like yeoman or something akin to angular-cli
or create-react-app
.
In the mean time, it is going to be clone/checkout based.
Here are some of the requirements I have for an MVP. I add more as I think of them.
- First class support for testing
- unit tests
- e2e tests
- coverage
- snapshot testing?
- storybook for components & layouts
- Easy development
- seemless debugging
- fast recompilation
- autogenerated documentation
- beautification
- dependency graph generation
- linting
- bundle analysis
- .d.ts generation
- Redux devtools browser extension
- Features
- router
- history
- authentication
- authorization
- logging
- animations
- CSS
- Greensock (imperative)
- react-pose (declarative)
- webworkers?
- metrics
- lazy-loading modules
- charts
- TypeScript
- react
- react-redux
- redux-saga
- webpack
- eslint
- prettier
- material-ui
- cosmos?
- gsap?
- react-pose?
- I prefer to split my application code along domain boundaries. This is opposed to another popular style where you have directories for "types" of application pieces e.g. /components, /services, /containers. I prefer this because I believe it fosters good programming practice.
- Unit Tests should live next to the files they test. When tests are in a complete separate directory structure, it's very easy to forget to move the test when refactoring the location of some domain code. Integration tests or e2e tests should live in a central location.
- Files should follow a predictable naming convention. I prefer dot separated files of the form:
domain.sub-clarifier.clarifier.ext
e.g.auth.domain.ts
,home.animation.banner.ts
File | Purpose |
---|---|
user.saga.ts |
Saga logic for the user domain |
route.domain.ts |
Domain types for the route domain |
auth.action.ts |
Redux actions for the auth domain |
auth.login.action.ts |
Hypothetical action file for auth domain where we felt it warranted its own file |
The basic idea is to create a starter project that represents a CICD tracking system that will have several modules:
- Users (admin)
- CRUD users
- User profile
- Update information
- View contributions
- Notifications
- Reports (admin)
- Build pass/fail stats
- Projects/contributions
- Builds
- Trigger/cancel builds
- View build history
We want this to be pseudo operational, so we will provide a docker-compose.yml
file that will spin up a populated database for testing with.
I wrote this on Linux, and so some of the project caters towards such a system. For example, linting uses the utility find
which is not from the windows world as well as *nix file paths. Additionally, I assume you have docker
and docker-compose
available for bringing up the database. If you are on Windows, then I recommend you use a linux VM. You can try using WSL, but YMMV.