Here's a working document of the proposed functionality and structure for rj so that we may "Command React".
❯ rj -h
rj, Command React
Usage
$ rj <command (default: help)>
Commands
generate, g
new, n
serve, s
test, t
build, b
Options
-fc, --functional-component
-st, --skip-test
-scn, --skip-container
-sc, --skip-component
-sa, --skip-action
-sr, --skip-reducer
-dr, --dry-run
-d, --environment=development
-p, --environment=production
-v, --verbose
-l, --location
-e, --environment (default: development)
-c, --config (default: .rj)
-cov, --coverage (default: false)
Examples
$ rj new awesome-project
$ rj generate component profile-card
$ rj generate component profile-card --functional-component
$ rj generate container users
$ rj generate reducer users
$ rj generate action users
$ rj generate pod users --skip-container
.rj
.babelrc
src/
router.js
index.html
components/
foo/
index.js
test.js
containers/
style/
store/
actions/
foo/
index.js
test/
test.js
reducers/
foo/
index.js
test/
fixtures/
some-data.json
test.js
pods/
foo/
container.js
action.js
component.js
route.js
test/
container-test.js
action-test.js
component-test.js
- Hotreloading
- Sass compilation
- Webpack config
- Development middleware
- Immutable js
- Configurable folder names
- Universal javascript
A pod (or mod/module) is essentially a standalone, grouped/namespaced collection of functionality. It will be added to the load path so pods/foo
can be imported with import Foo from 'foo/component'
.
It is intended/anticipated that collective groups/pages of components with a corresponing action and reducer will live in here to group things by logical parts.
When searching boilerplates I came across this one and love the distinction between a container and a component here:
- Containers are smart because they provide functions and data to the components. We also connect to redux at this level, grabbing reducer actions and state to also pass down to our components.]
- Components are dumb because they don't know anything about anything. They get data and functions passed in via props, and we try and avoid having any component state (including lifecycle events and refs). Your notice all the components in this boilerplate are using React's stateless component syntax.
Currently, this is a pretty straightforward implementation that essentially just adds generation/scaffolding niceties to a preconfigured project. However, after this step, we'd obviously like to do more:
- Addon ecosystem with
rwb
support. It would be great to be able torj install rj-postcss
or something of the like to automatically add postcss support to a project. - Some type of pluggable build system
- React native support