Commit a65de96b authored by Brandon Labuschagne's avatar Brandon Labuschagne Committed by Sarah Groff Hennigh-Palermo

Refactor based on review feedback

Place a general explaination at the top level
style guide and link to it from the vue and vuex
guides.
parent fedc70aa
...@@ -57,6 +57,66 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules) ...@@ -57,6 +57,66 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
1. Use `.vue` for Vue templates. Do not use `%template` in HAML. 1. Use `.vue` for Vue templates. Do not use `%template` in HAML.
1. Explicitly define data being passed into the Vue app
```javascript
// bad
return new Vue({
el: '#element',
components: {
componentName
},
provide: {
...someDataset
},
props: {
...anotherDataset
},
render: createElement => createElement('component-name'),
}));
// good
const { foobar, barfoo } = someDataset;
const { foo, bar } = anotherDataset;
return new Vue({
el: '#element',
components: {
componentName
},
provide: {
foobar,
barfoo
},
props: {
foo,
bar
},
render: createElement => createElement('component-name'),
}));
```
We discourage the use of the spread operator in this specific case in
order to keep our codebase explicit, discoverable, and searchable.
This applies in any place where we'll benefit from the above, such as
when [initializing Vuex state](../vuex.md#why-not-just-spread-the-initial-state).
The pattern above also enables us to easily parse non scalar values during
instantiation.
```javascript
return new Vue({
el: '#element',
components: {
componentName
},
props: {
foo,
bar: parseBoolean(bar)
},
render: createElement => createElement('component-name'),
}));
```
## Naming ## Naming
1. **Extensions**: Use `.vue` extension for Vue components. Do not use `.js` as file extension ([#34371](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/34371)). 1. **Extensions**: Use `.vue` extension for Vue components. Do not use `.js` as file extension ([#34371](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/34371)).
......
...@@ -66,29 +66,32 @@ You should only do this while initializing the application, because the mounted ...@@ -66,29 +66,32 @@ You should only do this while initializing the application, because the mounted
The advantage of providing data from the DOM to the Vue instance through `props` in the `render` function The advantage of providing data from the DOM to the Vue instance through `props` in the `render` function
instead of querying the DOM inside the main Vue component is avoiding the need to create a fixture or an HTML element in the unit test, instead of querying the DOM inside the main Vue component is avoiding the need to create a fixture or an HTML element in the unit test,
which will make the tests easier. See the following example: which will make the tests easier.
See the following example, also, please refer to our [Vue style guide](style/vue.md#basic-rules) for additional
information on why we explicitly declare the data being passed into the Vue app;
```javascript ```javascript
// haml // haml
#js-vue-app{ data: { endpoint: 'foo' }} #js-vue-app{ data: { endpoint: 'foo' }}
// index.js // index.js
document.addEventListener('DOMContentLoaded', () => new Vue({ const el = document.getElementById('js-vue-app');
el: '#js-vue-app',
data() { if (!el) return false;
const dataset = this.$options.el.dataset;
return { const { endpoint } = el.dataset;
endpoint: dataset.endpoint,
}; return new Vue({
}, el,
render(createElement) { render(createElement) {
return createElement('my-component', { return createElement('my-component', {
props: { props: {
endpoint: this.endpoint, endpoint
}, },
}); });
}, },
})); }
``` ```
> When adding an `id` attribute to mount a Vue application, please make sure this `id` is unique across the codebase > When adding an `id` attribute to mount a Vue application, please make sure this `id` is unique across the codebase
...@@ -100,7 +103,7 @@ By following this practice, we can avoid the need to mock the `gl` object, which ...@@ -100,7 +103,7 @@ By following this practice, we can avoid the need to mock the `gl` object, which
It should be done while initializing our Vue instance, and the data should be provided as `props` to the main component: It should be done while initializing our Vue instance, and the data should be provided as `props` to the main component:
```javascript ```javascript
document.addEventListener('DOMContentLoaded', () => new Vue({ return new Vue({
el: '.js-vue-app', el: '.js-vue-app',
render(createElement) { render(createElement) {
return createElement('my-component', { return createElement('my-component', {
...@@ -109,7 +112,7 @@ document.addEventListener('DOMContentLoaded', () => new Vue({ ...@@ -109,7 +112,7 @@ document.addEventListener('DOMContentLoaded', () => new Vue({
}, },
}); });
}, },
})); });
``` ```
#### Accessing feature flags #### Accessing feature flags
......
...@@ -360,8 +360,8 @@ export default initialState => ({ ...@@ -360,8 +360,8 @@ export default initialState => ({
``` ```
We've made the conscious decision to avoid this pattern to aid in the We've made the conscious decision to avoid this pattern to aid in the
discoverability and searchability of our frontend codebase. The reasoning for discoverability and searchability of our frontend codebase. The same applies
this is described in [this when [providing data to a Vue app](vue.md#providing-data-from-haml-to-javascript). The reasoning for this is described in [this
discussion](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/56#note_302514865): discussion](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/56#note_302514865):
> Consider a `someStateKey` is being used in the store state. You _may_ not be > Consider a `someStateKey` is being used in the store state. You _may_ not be
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment