Как улучшить архитектуру моего проекта для скрытия ненужных занятий в расписании? Я создаю клиентское расширение на JavaScript и телеграм-бота. Чтобы прослушивать изменения, я использую парсинг расписания на стороне клиента. Однако я хотел бы вынести эту логику парсинга на бэкенд для возможности повторного использования в телеграм-боте. Единственная идея, которая мне пришла в голову, заключается в следующем: если клиент не вносит изменений в расписание, то он просто отправляет загруженную HTML страницу на бэкенд, который возвращает распаршенное расписание в формате JSON, которое клиентское расширение хранит. Каждая ячейка имеет удобные атрибуты "день недели" и "время". Когда клиент вносит изменения, я считываю эти атрибуты, нахожу соответствующую запись в сохраненных данных на клиентской стороне и отправляю изменения обратно на сервер, который генерирует новую версию HTML расписания, которую я заменяю с помощью innerText. Понимаю, что это звучит ужасно и непрактично, но не могу придумать более эффективное решение. Как лучше сделать в данном случае?
Есть несколько способов улучшить архитектуру вашего проекта для повторного использования логики парсинга: 1. Создайте отдельный модуль для логики парсинга на бэкенде: Вынесите код парсинга в отдельный модуль, который можно будет использовать как в вашем клиентском расширении, так и в телеграм-боте. Этот модуль должен принимать HTML страницу в качестве входных данных и возвращать распаршенное расписание в формате JSON. Таким образом, вы сможете повторно использовать логику парсинга в обоих приложениях без необходимости дублирования кода. 2. Разработайте API для вашего бэкенда: Вместо отправки HTML страницы на бэкенд и получения обратно распаршенного расписания в формате JSON, рекомендуется создать API, которое будет принимать HTML страницу в качестве запроса и возвращать расписание в формате JSON. Это позволит вам более гибко управлять данными и избежать лишних операций с DOM. 3. Используйте базу данных для хранения расписания: Вместо того чтобы каждый раз отправлять изменения на сервер и генерировать новую версию HTML расписания, рекомендуется использовать базу данных для хранения расписания. Когда клиент вносит изменения, вы сохраняете их в базу данных и обновляете только необходимую информацию, не требуя повторного парсинга и генерации HTML. 4. Примените паттерны проектирования: Рассмотрите использование паттернов проектирования, таких как MVC (Model-View-Controller) или MVP (Model-View-Presenter) для разделения логики парсинга от представления и управления данными. Это позволит вам более гибко организовать ваш код и повторно использовать логику парсинга в различных частях приложения. Надеюсь, эти советы помогут вам улучшить архитектуру вашего проекта и повторно использовать логику парсинга в разных частях приложения.