Pull request should be a kind of documentation where you explain the context of your changes to your colleagues, not explaining the code, but explaining the business logic behind this change, why are you doing this work.

Template:


When you inspect the code above you should notice following problems:

• It exposes too many implementation details (shallow modules)
• The main component handles too many responsibilities
• State management is scattered and tightly coupled
• Position logic is leaked to multiple components
• Relationship handling is mixed with UI logic
• No clear separation of concerns
• Direct manipulation of complex state structures
• No abstraction of the underlying data model
• Business logic mixed with presentation logic

Solutioning Aspects

Each component and hook has a focused responsibility with a simple interface but complex internal implementation.

Complex state management is hidden in useBlockChain Block creation logic is encapsulated in BlockFactory Chain operations are isolated in ChainOperations

Components only depend on their immediate needs Business logic is separated from UI components State management is centralized and predictable

Components expose only what’s necessary State updates are handled through well-defined actions Complex operations are hidden behind simple method calls

UI components focus on rendering Business logic is in separate services State management is handled by specialized hooks

Each piece is independently testable Changes can be made without affecting other parts New features can be added by extending existing patterns

• Hide information: At the core of good design is information hiding. I need to encapsulate implementation details within modules so that changes to a module’s internals won’t ripple through the system.

• Avoid unnecessary dependencies: When implementation details are exposed, changes create tight coupling across the codebase. I need to ensure modules hide their internal state and logic to make future modifications easier.

• Centralize and hide complexity: Complexity should live inside modules, not spread across the system. I need to push complexity inward, exposing only simple interfaces to reduce cognitive load for other developers.

• Enable independent evolution: With hidden internals, modules can evolve independently. I need to design modules so changes in one area don’t break others, reducing maintenance costs and bugs.

• https://dev.to/nicolasmontielf/writing-a-good-pull-request-with-template-46pm
• https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository
• https://readmedium.com/en/https:/levelup.gitconnected.com/i-will-reject-your-pull-request-if-you-violate-these-design-principles-ded589981c0e