[ Brainstorming Voting Topic ] Frontend folder structure

[VargaElod23]

Separation of concerns:

• Single Responsibility Principle: Following the principle of Single Responsibility, each component should have a clear and well-defined responsibility. If a component requires too many props, it might be a sign that it is trying to handle too many different concerns and could benefit from being broken down into smaller components.
• Component Composition: Break down complex components into smaller, reusable components
• Container and Presentational Components
• React Hooks to encapsulate and reuse stateful logic within functional component
• Context API to share state across multiple components without manually passing props through intermediate components
• Component.styles.tsx files for defining component styles
• Interfaces vs Types - when to use interface when to create custom type?
• Interfaces - API data
• Types - component props
• Reduce the useEffect hook when possible
• Define max number of props passed down to a Child component - a maximum of around 5-7 props per component
• Define eslint rules for monorepo
• Don't use index from array as key
• DRY (Don't repeat yourself) - create reusable components/methods as much as possible
• SOLID
• When using useState and useEffects combined, best approach would be to move them both into a hook

File structure:

• api
• assets
• components (use storybook for these components)
• containers (smarter reusable components) or layouts?
• pages
• utils
• hooks
• context
• models
• theme
• features (used for more complex apps) - Inside each subfolder we can add pages, components, hooks etc.

Libraries to use:

• ethers (web3)
• luxon (date manipulation)
• react-query (fetching data) + axios
• react-hook-form (form manipulation)
• urql (graphql query) + graphql
• Tailwind vs Material UI vs Styled Components
• storybook
• wagmi
• Vite over CRA

[Malak67]

SOLID is an acronym that represents a set of five design principles for writing maintainable and scalable software.

Here's a brief overview of each principle:

Single Responsibility Principle (SRP): A class or module should have only one reason to change. It states that a class should have a single responsibility or job and should not be responsible for multiple, unrelated tasks. This principle promotes separation of concerns and helps to keep classes focused, maintainable, and easier to test.

Open-Closed Principle (OCP): Software entities (classes, modules, functions) should be open for extension but closed for modification. It means that you should be able to extend the behavior of a component without modifying its existing code. This is often achieved through the use of abstractions, interfaces, and inheritance or composition.

Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types. It emphasizes that objects of a superclass should be able to be replaced with objects of its subclasses without affecting the correctness of the program. In other words, derived classes should be able to be used wherever their base classes are used without causing unexpected behavior.

Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. It suggests that interfaces should be fine-grained and specific to the needs of the clients that use them. This principle helps prevent clients from depending on unnecessary or irrelevant methods and promotes cohesive interfaces.

Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions. This principle encourages decoupling and promotes the use of abstractions (interfaces or abstract classes) to define dependencies. It allows for flexibility, easier testing, and promotes the use of dependency injection.

By following the SOLID principles, developers can create code that is easier to understand, maintain, and extend over time. These principles encourage modular, loosely coupled, and highly cohesive code, leading to improved software design and scalability.