Моя статья действительно не затрагивает концепцию Local-First в том виде, как она описана на localfirstweb.dev. После Вашего комментария изменил название публикации, чтобы не путать читателей.
Про "раскладывание файликов":
Вы правы, что статья в основном фокусируется на организации файловой структуры. Однако, как я упоминал в других комментариях, мой подход — это не просто "раскладывание файликов", а попытка создать архитектуру, которая сочетает в себе четкое разделение ответственности и минимальную связанность между модулями. Это включает в себя не только организацию файлов, но и принципы взаимодействия между слоями (компоненты, виджеты, сервисы и т.д.).
Я согласен, что в статье не было глубокого погружения в теорию Local-First, и, возможно, название ввело в заблуждение. Local-First в моем контексте — это скорее метафора, которая подчеркивает, что архитектура строится вокруг локальной разработки и минимальной связанности между модулями. Это не столько про оффлайн-приложения, сколько про то, как сделать каждый модуль максимально независимым и самодостаточным (добавил это в дисклеймер после Вашего комментария).
Про зависимости между сторами:
Вы абсолютно правы, что со временем зависимости между сторами могут стать проблемой. В моем подходе я стараюсь минимизировать такие зависимости, вынося общую логику в сервисы или composables. Я бы отметил это как следующую степень развития проекта, но это отличная идея, подумаю над ее реализацией, спасибо!
Спасибо за ваш комментарий! Вы абсолютно правы: архитектура действительно в первую очередь описывает взаимодействие компонентов системы, а не просто организацию файлов. Я полностью согласен, что MVC/MVVM и другие архитектурные подходы ортогональны к способам организации файловой структуры, таким как FSD или Local-First.
Моя статья, возможно, не акцентировала внимание на этом различии достаточно четко. Однако мой подход не ограничивается только файловой структурой. Он также включает в себя принципы взаимодействия между слоями и модулями. Например:
Компоненты отвечают только за отображение и не содержат бизнес-логики.
Виджеты инкапсулируют логику, связанную с конкретными функциями, и могут взаимодействовать с сервисами.
Сервисы предоставляют общую логику для работы с данными и API.
Страницы объединяют виджеты и компоненты, обеспечивая их взаимодействие.
Таким образом, моя архитектура — это не просто способ организации файлов, а комбинация файловой структуры и принципов взаимодействия. Она не противоречит MVC/MVVM, а скорее дополняет их, предлагая конкретный способ организации кода, который помогает сохранять его чистым и поддерживаемым.
Ваш пример с Foo и Bar отлично иллюстрирует, как одна и та же архитектура (MVC) может быть реализована с разной файловой структурой. В моем случае я выбираю подход, который, с одной стороны, упрощает навигацию по проекту, а с другой — четко разделяет ответственность между слоями.
Интересный подход, но как будто бы он повторяет основной принцип MVVM (Model-View-ViewModel). Поправьте если это не так)
Но задумка в целом интересная, но я не могу ее представить в других фреймворках, том же Vue или Angular. Архитектура в этом плане узковатая, хотелось бы еще увидеть примеры не только в React
Любой фреймворк - это набор модулей (зависимостей), хранящихся в node_modules и прописанных в package.json. Эти модули могут быть как основными (например, Vue - это тоже модуль), так и второстепенными (всяческие ui-киты и т.д). Путем прописывания npm install эти модули подтягиваются в проект и их можно будет использовать внутри него.
В конечном счете все билдится в всеми любимые HTML, CSS, JS.
Обычный HTML без транспиляции может быть моментальным, но это не означает, что использование фреймворков не имеет преимуществ.
Фреймворки предоставляют готовые решения для различных задач и позволяют быстрее и эффективнее создавать веб-приложения. Так и плюс ко всему, фреймворки обеспечивают более структурированный и поддерживаемый код, а также повышают безопасность приложения.
Комментарий мой. Просто расписал его, чтобы комментатору было понятней.
Про Local-First:
Моя статья действительно не затрагивает концепцию Local-First в том виде, как она описана на localfirstweb.dev. После Вашего комментария изменил название публикации, чтобы не путать читателей.
Про "раскладывание файликов":
Вы правы, что статья в основном фокусируется на организации файловой структуры. Однако, как я упоминал в других комментариях, мой подход — это не просто "раскладывание файликов", а попытка создать архитектуру, которая сочетает в себе четкое разделение ответственности и минимальную связанность между модулями. Это включает в себя не только организацию файлов, но и принципы взаимодействия между слоями (компоненты, виджеты, сервисы и т.д.).
Про Local-First:
Я согласен, что в статье не было глубокого погружения в теорию Local-First, и, возможно, название ввело в заблуждение. Local-First в моем контексте — это скорее метафора, которая подчеркивает, что архитектура строится вокруг локальной разработки и минимальной связанности между модулями. Это не столько про оффлайн-приложения, сколько про то, как сделать каждый модуль максимально независимым и самодостаточным (добавил это в дисклеймер после Вашего комментария).
Про зависимости между сторами:
Вы абсолютно правы, что со временем зависимости между сторами могут стать проблемой. В моем подходе я стараюсь минимизировать такие зависимости, вынося общую логику в сервисы или composables. Я бы отметил это как следующую степень развития проекта, но это отличная идея, подумаю над ее реализацией, спасибо!
Спасибо за ваш комментарий! Вы абсолютно правы: архитектура действительно в первую очередь описывает взаимодействие компонентов системы, а не просто организацию файлов. Я полностью согласен, что MVC/MVVM и другие архитектурные подходы ортогональны к способам организации файловой структуры, таким как FSD или Local-First.
Моя статья, возможно, не акцентировала внимание на этом различии достаточно четко. Однако мой подход не ограничивается только файловой структурой. Он также включает в себя принципы взаимодействия между слоями и модулями. Например:
Компоненты отвечают только за отображение и не содержат бизнес-логики.
Виджеты инкапсулируют логику, связанную с конкретными функциями, и могут взаимодействовать с сервисами.
Сервисы предоставляют общую логику для работы с данными и API.
Страницы объединяют виджеты и компоненты, обеспечивая их взаимодействие.
Таким образом, моя архитектура — это не просто способ организации файлов, а комбинация файловой структуры и принципов взаимодействия. Она не противоречит MVC/MVVM, а скорее дополняет их, предлагая конкретный способ организации кода, который помогает сохранять его чистым и поддерживаемым.
Ваш пример с Foo и Bar отлично иллюстрирует, как одна и та же архитектура (MVC) может быть реализована с разной файловой структурой. В моем случае я выбираю подход, который, с одной стороны, упрощает навигацию по проекту, а с другой — четко разделяет ответственность между слоями.
Интересный подход, но как будто бы он повторяет основной принцип MVVM (Model-View-ViewModel). Поправьте если это не так)
Но задумка в целом интересная, но я не могу ее представить в других фреймворках, том же Vue или Angular. Архитектура в этом плане узковатая, хотелось бы еще увидеть примеры не только в React
Любой фреймворк - это набор модулей (зависимостей), хранящихся в
node_modulesи прописанных вpackage.json. Эти модули могут быть как основными (например, Vue - это тоже модуль), так и второстепенными (всяческие ui-киты и т.д). Путем прописыванияnpm installэти модули подтягиваются в проект и их можно будет использовать внутри него.В конечном счете все билдится в всеми любимые HTML, CSS, JS.
Как будто бы сейчас документация у Vue такая простая и понятная, что она спокойно заменит любой «чит-лист» :D
Я бы с огромным удовольствием помог, но, к сожалению, ни разу в жизни не работал с React
Это странно, а исходный файл с импортами компонентов правильно построен?
Прошу прощения, увидел, что меня пикнули здесь) Это ошибка или речь действительно про меня?
Спасибо большое! С Esbuild не работал, но наслышан о нем, нужно будет как-нибудь его попробовать
Обычный HTML без транспиляции может быть моментальным, но это не означает, что использование фреймворков не имеет преимуществ.
Фреймворки предоставляют готовые решения для различных задач и позволяют быстрее и эффективнее создавать веб-приложения. Так и плюс ко всему, фреймворки обеспечивают более структурированный и поддерживаемый код, а также повышают безопасность приложения.
Я не заставляю никого переходить, а лишь говорю о том, как это можно сделать.
Смысл перехода в том, что скорость разработки с Vite гораздо быстрее, чем при использовании Webpack. Приведу ниже таблицу.