Tools
A lot of good decisions have been made up to this point on the Sermon Cloud site, so we get the benefit of having some historical knowledge with these tools and can safely say that they are the current industry recommendations.
Due to the highly intereactive nature of the cms, I recommend we use:
- Webpack
- VueJS**
- Bootstrap
- Sass
- Sass-lint
- Babel
- ESlint
Organization
VueJS promotes single file components, that contain the html to build a part of a page, all of the js to make that html functional and all the css to style it.
So for example, rather than having a php file that builds the html for buttons, and styles for buttons in a global style sheet, and interactivity for buttons in a global js file, we will have a buttons.vue file that contains it all, and can be called with specific parameters to display the correct version of the button.
If we strictly follow Vue’s singe file component suggestion and Bootstraps UI, we shouldn’t need any global CSS or JS. In a real world, our goal should be to create a small global stylesheet to contain our bootstrap overrides.
**If we’re unable to use VueJS or another single file component framework I still recommend we follow the separation of concerns they recommend. Building our features as self-contained modules that know what css & js they require is the best way to ensure styles are consistent and code is reusable. It’s a better long term investment to have commonly used code in its own component rather than having global styles and 1-off implementations of html and js.
Style guides
A style guide is only useful if the team memorizes it and enforces it during code review. Tools like Sass-lint and ES-lint will automatically enforce our style guide rules at build time, eliminating the need to check code styles during reviews. I recommend we take the rules that we would like to follow, create lint rules that enforces them, and describe them in our own https://github.com/monkdev/standards
Existing style guides I recommend we take rules from:
- VueJS has its own styleguide
- AirBnB has style guides that are considered amongst the best in the industry (with lint rules)
- The creator of Bootstrap has an html & css style guide that is also very popular
Tools
A lot of good decisions have been made up to this point on the Sermon Cloud site, so we get the benefit of having some historical knowledge with these tools and can safely say that they are the current industry recommendations.
Due to the highly intereactive nature of the cms, I recommend we use:
Organization
VueJS promotes single file components, that contain the html to build a part of a page, all of the js to make that html functional and all the css to style it.
So for example, rather than having a php file that builds the html for buttons, and styles for buttons in a global style sheet, and interactivity for buttons in a global js file, we will have a buttons.vue file that contains it all, and can be called with specific parameters to display the correct version of the button.
If we strictly follow Vue’s singe file component suggestion and Bootstraps UI, we shouldn’t need any global CSS or JS. In a real world, our goal should be to create a small global stylesheet to contain our bootstrap overrides.
**If we’re unable to use VueJS or another single file component framework I still recommend we follow the separation of concerns they recommend. Building our features as self-contained modules that know what css & js they require is the best way to ensure styles are consistent and code is reusable. It’s a better long term investment to have commonly used code in its own component rather than having global styles and 1-off implementations of html and js.
Style guides
A style guide is only useful if the team memorizes it and enforces it during code review. Tools like Sass-lint and ES-lint will automatically enforce our style guide rules at build time, eliminating the need to check code styles during reviews. I recommend we take the rules that we would like to follow, create lint rules that enforces them, and describe them in our own https://github.com/monkdev/standards
Existing style guides I recommend we take rules from: