hyoushke/metabloc

🦄⚡ VITE template

💽Скрипты

1. "dev": запуск dev сервера приложения
2. "build:development", "build:production", "build:staging": билд приложения в соответствующем режиме
3. "preview": старт последней версии собранного приложения
4. "https-preview": старт последней версии собранного приложения в https режиме
5. "lint": запуск линтера без автофикса
6. "lint:fix": запуск линтера и автофикса
7. "check-types": проверка типов TS
8. "test": запуск unit тестов
9. "test:ci": запуск unit тестов для CI
10. "commit": коммит зарегестрированных в гит изменений
11. "generate-images": генерация responsive изображений
12. "ac": комлексная команда которая запустит линтер, проверит типы, добавит все изменения в гит и сделает коммит

🆔Naming

1. cebab-case, dot notaion
   • слова разделяются дефисом
   • все маленькие буквы
   • названия файла . тип файла . (ts | scss) ...
2. File types
   • .hook, .service, .util, .helper, .component, .types, .model, .config, .page
   • Для файлов констант и enums **scope**.constants.ts

📜Conventions

1. Все импорты между модулями делаем через alias, при необходимости можно добавить новые alias в проект
2. Для идентичности проектов React и Next пришлось выбрать вариант наименования страниц где в каждой папке со страницей лежит файл index.page.ts
3. Используется методология, которая не советует разделять файлы по их типам, следовательно если у вас есть хук use-create-user не надо создавать папку entities/user/hooks, а в ней файл use-create-user.hook.ts. Правильно будет создать файл use-create-user.hook.ts в папке entities/user/model или features/create-user/model
4. Обязательно Используем реэкспотры для реализации public api
5. Не используем any, используем as и satisfies где необходимо
6. Каталог pages: В каждой папке со страницей должен присутстовать файл index.page.ts в котором находится сам компонент страницы => пример pages/about/index.page.ts

Работа с изображениями

Растр

1. Добавляем изображения в папку public/assets/**
2. Используем команду npm run generate-images
3. Используем тэг <Image /> со свойством responsive=true

Пример:

import { Image } from "@shared/ui/image";

<Image
  alt=""
  sizes={{
    lg: '40rem',
  }}
  responsive
  src="/assets/random/random.jpg"
  loading="lazy"
/>

SVG

1. Добавляем иконку в src/shared/ui/icon/
2. Добавляем импорт в файл src/shared/ui/icon/icon.component.tsx Пример:

   const search = lazy(() => import('./search.svg'))
   
   const ICONS_MAP = {
     search,
   } as const

Пример:

import { IconComponent } from "@shared/ui/icon";
import { Suspense } from 'react'

<Suspense>
  <IconComponent
    alt="search icon"
    name="search" />
</Suspense>

📚Библиотеки

1. 🍞react-hoat-toast
   Используется для отображения нотификаций
   Документация

metabloc's Issues

Merge 'marketbloc-api' and 'marketbloc-chatbot' repositories

Description

Currently, the backend for marketbloc project is divided into two separate repositories; marketbloc-api for interacting with database storing user-specific data and marketbloc-chatbot for processing user prompts related to several services like shopify, mailchimp, google analytics.

While this approach may have been suitable during the initial development phase, it has now become apparent that maintaining two separate repositories is hindering the overall performance and response speed of the application in some cases, especially for multi-tenancy feature.

• When user wants to register/load/update the api_data for himself, marketbloc-chatbot application needs to communicate with marketbloc-api which in turn interact with database on cloud. So, this adds unnecessary layer of communication within the backend for the project.

• As new feature on [hyoushke/marketbloc-chatbot] may require the update on [hyoushke/marketbloc-api], maintaining these two repos separately might be problematic for version control of the project as a whole.

Solution

To improve the application's efficiency and simplify the development and deployment process, it is required to merge [hyoushke/marketbloc-api] and [hyoushke/marketbloc-chatbot] into a single, unified repository.
And, since this merging is required particularly for multi-tenancy feature, I think we can create a new unified repository with multi-tenancy feature.
This will allow us to:

1. Enhance Response Speed: By hosting the database and user-prompt processing components in the same repository, we can reduce the latency and improve the overall response time of the application, as the different components will be able to communicate directly, not through API calling.

2. Streamline Deployment: A single repository will simplify the deployment process, as we can manage the entire application's codebase and infrastructure from a single source of truth.

3. Maintain Version Control Consistency: Merging the repositories will ensure that the version control history and commit logs are maintained in a cohesive manner, simplifying the tracking and management of changes.

Todo

1. Create a new repository that will serve as the unified codebase for the application.
2. Migrate the existing code and assets from the two separate repositories into the new, unified repository.
3. Rebase the code base on a more advanced framework like django for future development.