Use this as a quick reference when you're deciding how to decompose your UI. PDF versions are also available below, so you can print it out and keep one under your pillow.
It is a common mistake to assign separate slides to the part of the code that is not reused anywhere. This mistake creates several problems at once:
- The codebase becomes more disjointed, making the code harder to navigate.
- A person reading your code, seeing that a slice is not part of the page, may begin to question whether they are breaking part of the display by changing that slice.
- This is a violation of basic principles such as KISS and Occam's Razor.
It can be avoided by following a simple rule: "Parts of code that are not reused anywhere should be where they are used".
For example, we have a component that contains a block of information about a user. This component is only used on the profile page, so it should stay on the profile page.
If you are sure that your slice will be used in more than one place, you can use the note below.
- (Thread) General logic for features and entities
- (Thread) Decomposition of swollen logic
- (Thread) About understanding the areas of responsibility during decomposition
- (Thread) Decomposition of the Product List widget
- (Article) Different approaches to the decomposition of logic
- (Thread) About the difference between features and entities
- (Thread) About the difference between things and entities (2)
- (Thread) About the application of criteria for decomposition
- (Thread) About decomposition by necessity