General animations are for simple animations on elements when a page loads/unloads.
`%p{ data: {'animate-in': 'animate-slide-up', 'animate-out': 'animate-slide-down' } }`
The attribute values will be added as class names to the p element on load/unload respectively.
The app will wait for data-animate-out animations to finish before loading the next page, therefore you must css animations rather than transitions.
Custom animations are for animating an element where a different element has triggered a page load.
%img{id: 'card-img-1' }
= link_to "Next page", next_page_path, data: {'custom-animation': 'animate-to-fullscreen', 'custom-animation-target': 'card-img-1'}
data-custom-animation value will be applied to the element that has the id of data-custom-animation-target
Revert animations apply when an element had a custom animation applied on the previous page and the user navigates back. It must keep the same id.
%img{ id: "card-img-1", data: {'revert-from-cache': '', 'animate-fallback': 'animate-slide-out-down'} }
When loading the previous page, it will animate back to it's previous size and position.
If navigating to a different page, the data-animate-fallback value will be added as a class instead.
- Ruby 2.5.1
- yarn
- bundle
$ bundle install
Run
$ cp config/database.yml.example config/database.yml
Edit config/database.yml and update the database name for the development and test entry
Then setup your database
$ rake db:setup
Install the required packages
$ yarn install
If you are using Tmuxinator, webpacker server will be started as part of your instance. If you want to start the webpack server on your own, please run
$ ./bin/webpack-dev-server
Install the heroku CLI tools link
Then run
$ heroku local
Edit config/tmuxinator.yml and change the app name
Then run
$ ln -s config/tmuxinator.yml ~/.tmuxinator/[app_name].yml
You should now be able to launch the project with
$ tmuxinator app_name
You will need to create a few variables on your Heroku app instance.
APPLICATION_HOSTto receive something likewww.appdomain.comASSET_HOSTto either receive something likewww.appdomain.comor will use APPLICATION_HOST if not presentMAX_THREADSdefault to 2RAILS_SERVE_STATIC_FILESdefault toenabledWEB_CONCURRENCYdefault to 2BUGSNAG_API_KEYto receive your Bugsnag's project API KEYSKYLIGHT_AUTHENTICATIONto receive your Skylight authentication IDSECRET_KEY_BASEto generate withrake secret
Rails assets:precompile requires the dev dependencies to be installed for compiling the assets. By default, Heroku doesn't pull them and you need to set those two environment variables for that:
$ heroku config:set NPM_CONFIG_PRODUCTION=false YARN_PRODUCTION=false
If using Skylight, you will need to activate the dyno metadata feature
$ heroku labs:enable runtime-dyno-metadata -a <app name>
You will need to add the following buildpacks:
- heroku/nodejs
- heroku/ruby
Linting helps ensure consistent code style and catch possible issues early. It is set up for both JavaScript and SCSS files.
JS linting is done through ESLint with the help of prettier for consistent code formatting. Configuration is in .eslintrc.js, with .eslintignore to ignore specific files. A script is setup in the package.json to lint all JS files in the app/webpack folder:
$ yarn lint:js
### SCSS linting
SCSS linting, it is Stylelint that does the work. Configuration is in .stylelintrc.js, with .stylelintignore to ignore specific files. As for JS, a script is setup in package.json to lint all SCSS files in the app/webpack folder.
$ yarn lint:css
Installing the front-end dependencies through yarn install also sets up commit hooks that will lint the JS and SCSS files you commit. They'll try to autocorrect errors by default (so you don't have to worry about formatting issues for ex.). If there are manual fixes to apply, please fix and re-commit. If really you need to commit without caring about those linting issues ( :( )), you can use the --no-verify flag at the end of your commit, which will let the commit go through without linting.