@@ -201,6 +201,72 @@ By following this pattern we guarantee:
1. All data in the application follows the same lifecycle pattern
1. Unit tests are easier
#### Updating complex state
Sometimes, especially when the state is complex, is really hard to traverse the state to precisely update what the mutation needs to update.
Ideally a `vuex` state should be as normalized/decoupled as possible but this is not always the case.
It's important to remember that the code is much easier to read and maintain when the `portion of the mutated state` is selected and mutated in the mutation itself.
Given this state:
```javascript
exportdefault()=>({
items:[
{
id:1,
name:'my_issue',
closed:false,
},
{
id:2,
name:'another_issue',
closed:false,
}
]
});
```
It may be tempting to write a mutation like so:
```javascript
// Bad
exportdefault{
[types.MARK_AS_CLOSED](state,item){
Object.assign(item,{closed:true})
}
}
```
While this approach works it has several dependencies:
- Correct selection of `item` in the component/action.
- The `item` property is already declared in the `closed` state.
- A new `confidential` property would not be reactive.
- Noting that `item` is referenced by `items`
A mutation written like this is harder to maintain and more error prone. We should rather write a mutation like this:
```javascript
// Good
exportdefault{
[types.MARK_AS_CLOSED](state,itemId){
constitem=state.items.find(i=>i.id==itemId);
Vue.set(item,'closed',true)
state.items.splice(index,1,item)
}
}
```
This approach is better because:
- It selects and updates the state in the mutation, which is more maintainable.
- It has no external dependencies, if the correct `itemId` is passed the state is correctly updated.
- It does not have reactivity caveats, as we generate a new `item` to avoid coupling to the initial state.
A mutation written like this is easier to maintain. In addition, we avoid errors due to the limitation of the reactivity system.
### `getters.js`
Sometimes we may need to get derived state based on store state, like filtering for a specific prop.
msgid "Note that PostgreSQL 11 will become the minimum required PostgreSQL version in GitLab 13.0 (May 2020). PostgreSQL 9.6 and PostgreSQL 10 will no longer be supported in GitLab 13.0. Please consider upgrading your PostgreSQL version (%{db_version}) soon."
msgid "Note that PostgreSQL %{pg_version_upcoming} will become the minimum required version in GitLab %{gl_version_upcoming} (%{gl_version_upcoming_date}). Please consider upgrading your environment to a supported PostgreSQL version soon, see <a href=\"%{pg_version_upcoming_url}\">the related epic</a> for details."
msgstr ""
msgid "Note that this invitation was sent to %{mail_to_invite_email}, but you are signed in as %{link_to_current_user} with email %{mail_to_current_user}."
...
...
@@ -16707,7 +16707,7 @@ msgstr ""
msgid "People without permission will never get a notification."
msgstr ""
msgid "Percent rollout (logged in users)"
msgid "Percent of users"
msgstr ""
msgid "Percentage"
...
...
@@ -25502,6 +25502,9 @@ msgstr ""
msgid "User IDs"
msgstr ""
msgid "User List"
msgstr ""
msgid "User Lists can only be created and modified with %{linkStart}the API%{linkEnd}"
msgstr ""
...
...
@@ -26648,6 +26651,9 @@ msgstr ""
msgid "You are trying to upload something other than an image. Please upload a .png, .jpg, .jpeg, .gif, .bmp, .tiff or .ico."
msgstr ""
msgid "You are using PostgreSQL %{pg_version_current}, but PostgreSQL %{pg_version_minimum} is required for this version of GitLab. Please upgrade your environment to a supported PostgreSQL version, see %{pg_requirements_url} for details."
msgstr ""
msgid "You can %{linkStart}view the blob%{linkEnd} instead."
