diff options
Diffstat (limited to 'doc/development/fe_guide/design_anti_patterns.md')
-rw-r--r-- | doc/development/fe_guide/design_anti_patterns.md | 11 |
1 files changed, 6 insertions, 5 deletions
diff --git a/doc/development/fe_guide/design_anti_patterns.md b/doc/development/fe_guide/design_anti_patterns.md index 0788921fce4..9e602b1ea04 100644 --- a/doc/development/fe_guide/design_anti_patterns.md +++ b/doc/development/fe_guide/design_anti_patterns.md @@ -12,7 +12,8 @@ generally be avoided. Throughout the GitLab codebase, there may be historic uses of these anti-patterns. Please [use discretion](https://about.gitlab.com/handbook/engineering/#balance-refactoring-and-velocity) when figuring out whether or not to refactor, when touching code that uses one of these legacy patterns. -**Please note:** For new features, anti-patterns are not necessarily prohibited, but it is **strongly suggested** to find another approach. +NOTE: +For new features, anti-patterns are not necessarily prohibited, but it is **strongly suggested** to find another approach. ## Shared Global Object (Anti-pattern) @@ -59,7 +60,7 @@ Shared Global Object's solve the problem of making something globally accessible could be appropriate: - When a responsibility is truly global and should be referenced across the application - (e.g., an application-wide Event Bus). + (for example, an application-wide Event Bus). Even in these scenarios, please consider avoiding the Shared Global Object pattern because the side-effects can be notoriously difficult to reason with. @@ -136,8 +137,8 @@ many problems with a module that exports utility functions. Singletons solve the problem of enforcing there to be only 1 instance of a thing. It's possible that a Singleton could be appropriate in the following rare cases: -- We need to manage some resource that **MUST** have just 1 instance (i.e. some hardware restriction). -- There is a real [cross-cutting concern](https://en.wikipedia.org/wiki/Cross-cutting_concern) (e.g., logging) and a Singleton provides the simplest API. +- We need to manage some resource that **MUST** have just 1 instance (that is, some hardware restriction). +- There is a real [cross-cutting concern](https://en.wikipedia.org/wiki/Cross-cutting_concern) (for example, logging) and a Singleton provides the simplest API. Even in these scenarios, please consider avoiding the Singleton pattern. @@ -174,7 +175,7 @@ export const fuzzify = (id) => { /* ... */ }; #### Dependency Injection [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection) is an approach which breaks -coupling by declaring a module's dependencies to be injected from outside the module (e.g., through constructor parameters, a bona-fide Dependency Injection framework, and even Vue's `provide/inject`). +coupling by declaring a module's dependencies to be injected from outside the module (for example, through constructor parameters, a bona-fide Dependency Injection framework, and even Vue's `provide/inject`). ```javascript // bad - Vue component coupled to Singleton |