- Client vs server rendering
- Hmr and hot reloading with the webpack dev server
- How to use different files for client and server rendering
- React server rendering
- Render functions and railscontext
- Rspec configuration
- Webpack configuration
- Upgrading react on rails
- React on rails overview
- Minitest configuration
- How to conditionally server render based on device type
- How react on rails works
- Installation into an existing rails app
- Rails webpacker react integration options
- File system based automated bundle generation
- Convert rails 5 api only app
- Rails engine integration
- Asset pipeline
- Capistrano deployment
- Converting from custom webpack config to rails webpacker config
- Code splitting
- Angular js integration migration
- Foreman issues
- React and redux
- React router
- React helmet
- Server rendering tips
- Troubleshooting when using webpacker
- Webpack v1 notes
- Node dependencies and npm
- Generator details
- Migrating from react rails
- Updating dependencies
- Upgrade webpacker v3 to v4
- Manual installation overview
- Recommended project structure
- Errors with hooks
- Pull requests
- Generator testing
Copyright 2020 ShakaCode
Checklist before Committing
rake: runs all linters and specs (you need Docker setup, see below)
- Did you need any more tests for your change?
- Did you document your change? Update the README.md?
- Did you add a CHANGELOG.md entry?
For non-doc fixes:
- Provide changelog entry in the unreleased section of the CHANGELOG.md.
- Ensure CI passes and that you added a test that passes with the fix and fails without the fix.
- Squash all commits down to one with a nice commit message ONLY once final review is given. Make sure this single commit is rebased on top of master.
- Please address all code review comments.
- Ensure that docs are updated accordingly if a feature is added.
From How to Write a Git Commit Message
The seven rules of a great git commit message
Keep in mind: This has all been said before.
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
When making doc changes, we want the change to work on both the gitbook and the regular github site. The issue is that non-doc files will not go to the gitbook site, so doc references to non doc files must use the github URL.
Links to other docs:
When making references to doc files, use a relative URL path like:
When making references to source code files, use a full url path like: