Most of the DADI platform is built on Node.js, which means access to a plethora of ways to manage front-end workflow within your app: Bower, Grunt, Gulp, Webpack are just a few.
At DADI we find the majority of our front-end needs can be met with simple chaining of NPM scripts - eliminating another level of abstraction and one less dependancy.
🔗Folder structure
Assuming you have installed DADI Web you can begin to setup your folder structure. A typical folder structure for us looks like the following:
workspace/
├── datasources/
├── events/
├── frontend/
| ├── lib/
| ├── sass/
| └── src/
├── middleware/
├── pages/
├── public/
| └── assets/
| ├── img/
| ├── css/
| └── js/
├── routes/
└── utils/
frontend/lib
Any libraries that we have written ourselves, or cannot be found on NPM.
frontend/sass
Sass gives us an improved CSS syntax so we can write less code which is more modular and easy to follow.
frontend/src
Here we store the source files for each Javascript module we write.
public/assets
These three folders, img
, css
and js
the publicly accessible endpoint for assets to be served through DADI Web.
🔗NPM scripts
Typically you will use npm start
to start DADI Web, but we can also use these commands to initiate a build script for us. We are going to assign ours to npm run build
.
First off, here’s what the final package.json
looks like. It might seem messy, but if you follow along from top to bottom it is in a logical order.
{
"scripts": {
"prebuild": "mkdir -p workspace/public/assets/css workspace/public/assets/js",
"build:css": "node-sass workspace/frontend/sass/main.scss workspace/public/assets/css/main.css --source-map-embed true --source-map-contents true",
"postbuild:css": "postcss workspace/public/assets/css/main.css --use postcss-import --use autoprefixer --autoprefixer.browsers '> 1%' --use postcss-clean -o workspace/public/assets/css/main.min.css --replace --map",
"prebuild:js": "jshint workspace/frontend/src/**.js",
"build:js": "browserify workspace/frontend/src/**.js --debug | exorcist workspace/public/assets/js/main.js.map > workspace/public/assets/js/main.js",
"postbuild:js": "uglifyjs workspace/public/assets/js/main.js -o workspace/public/assets/js/main.min.js"
},
"devDependencies": {
"autoprefixer": "^7.1.4",
"browserify": "^14.5.0",
"exorcist": "^1.0.0",
"jshint": "^2.9.5",
"node-sass": "^4.7.2",
"postcss-clean": "^1.1.0",
"postcss-cli": "^4.1.1",
"postcss-import": "^11.0.0",
"uglify-js": "^3.2.0"
}
}
prebuild
This is a simple command to create the folders we discussed previously (incase they don’t exist for whatever reason).build
Although we haven’t expressively said it, when wenpm run build
it will run the child scripts delimitated by the:
, therefore the next two will be run.build:css
Use node-sass to compile our CSS from Sass - for smaller projects you may not even need this extra toolset, but we find it helps larger projects stay organized.postbuild:css
Use PostCSS to import other CSS files ‘require’ style, add vendor prefixes and then minify the output…or any other PostCSS plugin you want.prebuild:js
Use JSHint to check for any code issues (this will stop the process and flag any errors in your terminal).build:js
Use Browserify to compile thesrc/
folder into a single JS file. We then use exorcist to create a sourcemap.postbuild:js
Use UglifyJS to minify the output.
🔗Sourcemaps only for debugging
We now have a minified and non-minified version of our JS and CSS. For an extra touch you can load the non-minified version, including sourcemaps, when you’re in debug mode. For example using ES6 template syntax:
<link rel="stylesheet" href="/assets/css/main${debug ? '.min' : ''}.css">
<script src="/assets/js/main${debug ? '.min' : ''}.js"></script>
🔗Conclusion
Hopefully that’s covered an average setup. Once you get familiar with all the CLI tools out there you can begin to add more customisation – such as live reloading and transpiling your JS. Questions? Find us on Discord.