diff --git a/SUMMARY.md b/SUMMARY.md index 8d8d81534..11c4b0293 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -7,15 +7,10 @@ * [Backend](backend/README.md) * [GraphQL](backend/graphql.md) * [Webapp](webapp/README.md) - * [COMPONENTS](webapp/components.md) - * [PLUGINS](webapp/plugins.md) - * [STORE](webapp/store.md) - * [PAGES](webapp/pages.md) - * [ASSETS](webapp/assets.md) - * [LAYOUTS](webapp/layouts.md) - * [Styleguide](webapp/styleguide.md) - * [STATIC](webapp/static.md) - * [MIDDLEWARE](webapp/middleware.md) + * [Components](webapp/components.md) + * [HTML](webapp/html.md) + * [SCSS](webapp/scss.md) + * [Vue](webapp/vue.md) * [Testing Guide](testing.md) * [End-to-end tests](cypress/README.md) * [Frontend tests](webapp/testing.md) diff --git a/webapp/components.md b/webapp/components.md index 186206d67..ea99214ec 100644 --- a/webapp/components.md +++ b/webapp/components.md @@ -28,3 +28,11 @@ The `Card` on the other hand does not care about the type of data it needs to ha We follow the W3C rules for naming custom elements as suggested in the [Vue.js docs](https://vuejs.org/v2/guide/components-registration.html#Component-Names) to differentiate our own components from regular HTML elements in our templates. Names should also be meaningful and unique to avoid confusion and code duplication, and also not too long to make them readable. Therefore: aim for two-word names, such as `layout-card`, `post-list` or `post-teaser`. + +## Recommended reads + +For a deeper dive into the WHY and HOW have a look at the following resources which the above guidelines are based on: + +- [Atomic design](https://bradfrost.com/blog/post/atomic-web-design/) +- [CDD – component based design](https://medium.com/@wereheavyweight/how-were-using-component-based-design-5f9e3176babb) +- [Vue.js component styleguide](https://pablohpsilva.github.io/vuejs-component-style-guide/#/) diff --git a/webapp/scss.md b/webapp/scss.md index d9a9dc1ea..e8a48792f 100644 --- a/webapp/scss.md +++ b/webapp/scss.md @@ -64,3 +64,10 @@ To do that, use the `child selector`, like this: ``` A special case are dimensions like `width` and `height`. If it is important that a component always has the same dimensions (the height of a button should be consistent, for example) define it _within the component_ itself, if a component should have flexible dimensions (a card, for example, could stretch over the whole screen in one place and be limited to a certain width in another) define the dimensions _in the parent_. + +## Recommended reads + +For a deeper dive into the WHY and HOW have a look at the following resources which the above guidelines are based on: + +- [rscss – reasonable system for css stylesheet structure](https://rscss.io/index.html) +- [itcss – inverted triangle architecture for css](https://csswizardry.net/talks/2014/11/itcss-dafed.pdf) diff --git a/webapp/vue.md b/webapp/vue.md new file mode 100644 index 000000000..47d0620f0 --- /dev/null +++ b/webapp/vue.md @@ -0,0 +1,53 @@ +# Vue – Code Guidelines + +## We use single-file components + +Each component lives in a single file, containing: +- its `template` (the DOM structure) +- its `script` (including `props`, `data` and `methods` among other things) +- its `style` (defining the look of the component) + +See the [Vue.js docs](https://vuejs.org/v2/guide/single-file-components.html) for more details. + +Placed in the same folder are also: +- the test file (e.g. `MyComponent.spec.js`) +- the storybook file (e.g. `MyComponent.story.js`) + +## We use typed props + +Vue.js allows us to define component props either as strings or as objects with `type`, `default` and `required` values. Always go for the second option! + +Also: define defaults _only and always_ for non-required props. + +Why? +- it makes our code more robust – a warning will be shown when passing a wrong prop type +- it clearly defines the component API and tells other developers how to use it + +It is as easy as writing: + +``` +props: { + title: { + type: String, + required: true, + }, + image: { + type: String, + default: 'human-connection-logo.png', + }, +} +``` + +For more complex use cases see the [official Vue.js documentation](https://vuejs.org/v2/guide/components-props.html#Prop-Validation). + +## We use shorthands + +For better readability we prefer +- `:something` over `v-bind:something` +- `@click` over `v-on:click` + +Read more in the [official Vue.js docs](https://vuejs.org/v2/guide/syntax.html#Shorthands) + +## Recommended reads + +The [Vue.js component style guide](https://pablohpsilva.github.io/vuejs-component-style-guide/#/?id=harness-your-component-props) offers a whole list of best-practices for writing Vue components.