User guide & vale setup (#2260)

* refactored Storybook UI

* refactored Storybook UI

* removed extra cards from the doc, added card for ui components

* added hover behavior to doc page & made it look selected

* separate storybook docs and tests

* separating storybook tests and docs

* fixed spelling errors in docs

* Final round of edits for frontend, added backend folder architecture

* Created CODE_OF_CONDUCT.md

* Add code of conduct to contributing.md

* doc changes

* fixed broken links

* doc addition and changes

* introduce user guide & graphql api

* set up vale, added to docs

* vale config file

* revised backend best practices

* connecting zapier and twenty

* added warning for zapier
This commit is contained in:
Nimra Ahmed
2023-10-30 22:01:58 +05:00
committed by GitHub
parent 7cb58eae4d
commit a523190943
46 changed files with 2254 additions and 20 deletions

View File

@ -0,0 +1,26 @@
---
title: Best Practices
sidebar_position: 3
sidebar_custom_props:
icon: TbChecklist
---
This document outlines the best practices you should follow when working on the backend.
## Follow a modular approach
We follow a modular approach for our backend, which is a fundamental principle when working with NestJS. Make sure you break down your code into reusable modules to maintain a clean and organized codebase.
Each module should encapsulate a particular feature or functionality and have a well-defined scope. This modular approach enables clear separation of concerns and removes unnecessary complexities.
## Expose services to be used in modules
We encourage creating services that have a clear and single responsibility, which enhances code readability and maintainability. Services should be named descriptively and consistently.
We also encourage exposing services to be used in other modules. Exposing services to other modules is made possible through NestJS's powerful dependency injection system, and promotes loose coupling between components.
## Avoid using `any` type
When you declare a variable as `any`, TypeScript's type checker doesn't perform any type checking, making it possible to assign any type of values to the variable. TypeScript is designed to use type inference to determine the type of variable based on the value. By declaring it as `any`, TypeScript can no longer infer the type. This makes it hard to catch type-related errors during development, leading to runtime errors and makes the code less maintainable, less reliable, and harder to understand for others.
This is why everything should be typed. So if you create a new object with a first name and last name, you should create an interface or type that contains a first name and last name that defines the shape of the object you are manipulating.