summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSimon Knox <psimyn@gmail.com>2018-11-30 09:19:37 +1100
committerSimon Knox <psimyn@gmail.com>2018-11-30 09:19:37 +1100
commitaac6439dee2261973a4c6e9b01333379a8c81449 (patch)
tree31b0a52ccfea3202c20d24361c7eb4dafd1342ba
parent5e38a97b8d26878afb91029e1b2d9bc25fd56f69 (diff)
downloadgitlab-ce-docs-fe-design-pattern.tar.gz
Delete outdated partsdocs-fe-design-pattern
-rw-r--r--doc/development/new_fe_guide/development/design_patterns.md47
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