diff options
author | Simon Knox <psimyn@gmail.com> | 2018-11-30 09:19:37 +1100 |
---|---|---|
committer | Simon Knox <psimyn@gmail.com> | 2018-11-30 09:19:37 +1100 |
commit | aac6439dee2261973a4c6e9b01333379a8c81449 (patch) | |
tree | 31b0a52ccfea3202c20d24361c7eb4dafd1342ba | |
parent | 5e38a97b8d26878afb91029e1b2d9bc25fd56f69 (diff) | |
download | gitlab-ce-docs-fe-design-pattern.tar.gz |
Delete outdated partsdocs-fe-design-pattern
-rw-r--r-- | doc/development/new_fe_guide/development/design_patterns.md | 47 |
1 files changed, 5 insertions, 42 deletions
diff --git a/doc/development/new_fe_guide/development/design_patterns.md b/doc/development/new_fe_guide/development/design_patterns.md index 39ca161c667..983b451d2fc 100644 --- a/doc/development/new_fe_guide/development/design_patterns.md +++ b/doc/development/new_fe_guide/development/design_patterns.md @@ -1,28 +1,5 @@ # Design patterns -## Mediator - -The [mediator pattern][mediator-pattern] is a common design pattern used in GitLab frontend to ensure that a single network request can update the store of two or more different Vue apps. - -Each page on GitLab is made up of multiple Vue apps and each app has it's own separate concerns. However, sometimes these Vue app's leverage the same network request to fetch data (E.g. Issuable sidebar items). In these cases, it would be ideal to take advantage of the mediator pattern, so that only one network request is needed to fetch the data, rather than one network request for each Vue app on the page. - -<script src="https://unpkg.com/mermaid@7.1.2/dist/mermaid.min.js"></script> -<script>mermaid.initialize({startOnLoad:true});</script> -**Without Mediator** -<div class="mermaid"> -graph TD - A(Vue App 1's service) -- fetches --> C(API endpoint) - B(Vue App 2's service) -- fetches --> D(API endpoint) -</div> - -**With Mediator** -<div class="mermaid"> -graph TD - A(Vue App 1's service) -- fetches --> C(Vue App 1 and 2's mediator) - B(Vue App 2's service) -- fetches --> C(Vue App 1 and 2's mediator) - C(Common mediator) -- fetches -->D(API endpoint) -</div> - ## Realtime features We use polling to simulate realtime features at GitLab. Here is the general architecture setup. @@ -56,30 +33,16 @@ new_feature │ └── new_feature_store.js ├── service │ └── new_feature_service.js -└── new_feature_bundle.js +└── index.js ``` -#### Bundle file - -This bundle file should include the root Vue instance of the new feature. The Store and Service should be imported, initialized and provided as a prop to the main component. +#### Index file -#### Store +This index file should include the root Vue instance of the new feature. The Store and Service should be imported, initialized and provided as props to the main component. -We follow the [Flux architecture][flux-architecture] for all Vue features. Flux follows the unidirectional data flow pattern and is easier to maintain and debug. -We have two methods for implementing Flux. +#### Vuex -1. Vue store pattern -2. Vuex - -##### Vue store pattern - -> TODO: Add Content - -##### Vuex - -> TODO: Add Content +We use Vuex for managing data. -[mediator-pattern]: https://en.wikipedia.org/wiki/Mediator_pattern [poll-js]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/lib/utils/poll.js [visibility-js]: https://github.com/ai/visibilityjs -[flux-architecture]: https://facebook.github.io/flux |