2. Постановка задачи

Разработать клиентскую часть веб-приложения «Медицинский портал», работающую в браузере и взаимодействующую с серверной частью, реализованной на основе Flask и MySQL. В качестве прототипа интерфейса можно использовать современные медицинские порталы (ЕМИАС, онлайн-запись в частные клиники). Для работы с данными следует предусмотреть слой взаимодействия с API. Моей задачей в рамках данного проекта было создание полноценной клиентской части веб-приложения медицинского портала. Остальные требования к архитектуре определяются студентом самостоятельно.

Разрабатываемая клиентская часть должна быть создана с использованием следующих технологий:

· фронтенд: HTML5, CSS3, JavaScript (ES6+),

· стилизация: CSS Grid, Flexbox, адаптивная вёрстка,

· иконки: Font Awesome 6,

· взаимодействие с сервером: Fetch API,

· структура проекта: модульный JavaScript (классы),

· хранение локальных данных: Web Storage API (localStorage).

Клиентская часть должна обеспечивать выполнение следующих операций:

· отображение каталога клиник с фильтрацией и поиском,

· интерактивную систему записи на приём с выбором клиники, врача и времени,

· визуализацию календаря занятости с детализацией по дням,

· управление корзиной медицинских услуг (добавление, удаление, оформление заказа),

· отображение личных записей пользователя,

· удаление записи на прием,

· обработку состояния авторизации пользователя,

· систему уведомлений о действиях пользователя.

Интерфейсная часть программы должна содержать следующие компоненты:

· главная страница с системой вкладок (табов),

· адаптивный дизайн, работающий на мобильных устройствах и десктопах,

· интерактивный календарь с визуальными индикаторами занятости,

· модальные окна для дополнительных действий,

· динамическую загрузку данных без перезагрузки страницы,

· индикаторы загрузки и состояния системы.

Пояснительная записка должна содержать:

· постановку задачи применительно к frontend-разработке,

· обоснование выбранных фронтенд-технологий,

· разработку архитектуры клиентской части,

· разработку отдельных UI-компонентов и JavaScript-модулей,

· инструкцию по использованию интерфейса,

· заключение,

· список литературы,

· приложения.

3. Обоснование выбора технологий

Выбор чистого JavaScript (ES6+) без фреймворков:

JavaScript ES6+ был выбран в качестве основы клиентской логики по следующим причинам:

Преимущества, определившие выбор:

1. Отсутствие дополнительных зависимостей — чистый JavaScript не требует сборки, транспиляции и установки дополнительных пакетов, что упрощает развёртывание и уменьшает размер конечного приложения.

2. Прямой доступ к DOM API — работа с нативными API браузера обеспечивает глубокое понимание основ frontend-разработки и полный контроль над поведением интерфейса.

3. Высокая производительность — отсутствие накладных расходов, характерных для фреймворков, обеспечивает быструю отрисовку интерфейса и отклик на действия пользователя.

4. Современный синтаксис — возможности ES6+ (классы, промисы, async/await, деструктуризация) позволяют писать чистый и поддерживаемый код, сравнимый по качеству с кодом на фреймворках.

5. Совместимость с серверной частью — прямой Fetch API идеально интегрируется с Flask REST API, обеспечивая простой обмен данными в формате JSON.

Рассмотренные альтернативы и причины их отклонения:

· React/Vue.js — отклонены из-за излишней сложности для учебного проекта и необходимости изучения дополнительных концепций (виртуальный DOM, состояние компонентов);

· jQuery — отклонена как устаревшая технология, не использующая современные возможности JavaScript;

· TypeScript — отклонён из-за дополнительного шага транспиляции и избыточности для проекта данного масштаба.

Выбор CSS Grid и Flexbox для вёрстки:

CSS Grid и Flexbox были выбраны в качестве технологий макетирования по следующим критериям:

Критические требования, удовлетворяемые этими технологиями:

1. Сложные адаптивные макеты — медицинский портал требует отображения различной информации в разных контекстах (каталог клиник, календарь, корзина), что эффективно реализуется с помощью комбинации Grid и Flexbox.

2. Контроль над расположением элементов — точное позиционирование компонентов интерфейса критически важно для удобства использования.

3. Адаптивность без медиа-запросов — многие аспекты адаптивности могут быть реализованы средствами самих Grid и Flexbox, уменьшая количество медиа-запросов.

Сравнение с альтернативными решениями:

· CSS-фреймворки (Bootstrap, Tailwind) — обеспечивают быстрый старт, но создают избыточность и ограничивают кастомизацию;

· Табличная вёрстка — устаревший подход, не поддерживающий современные требования к адаптивности;

· Float-вёрстка — сложна в поддержке и не предназначена для сложных макетов.

Выбор Fetch API для взаимодействия с сервером:

Fetch API был выбран для выполнения HTTP-запросов по следующим соображениям:

Ключевые преимущества:

1. Нативность и поддержка браузерами — не требует дополнительных библиотек, поддерживается всеми современными браузерами.

2. Простота использования — понятный Promise-based API с поддержкой async/await.

3. Интеграция с современным JavaScript — естественно вписывается в асинхронную модель ES6+.

4. Гибкость — позволяет настроить любые параметры запроса (заголовки, метод, тело, кеширование).

Сравнение с альтернативами:

· XMLHttpRequest — устаревший, сложный в использовании API с callback-based подходом;

· WebSocket — не подходит для REST-взаимодействия, предназначен для двусторонней связи в реальном времени.

Выбор localStorage для хранения состояния корзины:

Web Storage API (localStorage) был выбран для временного хранения данных корзины:

Обоснование выбора:

1. Простота использования — синхронный API с ключ-значение структурами.

2. Сохранение данных между сессиями — пользователь не теряет содержимое корзины при обновлении страницы.

3. Отсутствие серверной нагрузки — данные корзины хранятся локально до оформления заказа.

4. Интеграция с JSON — возможность хранить структурированные данные через сериализацию.

Альтернативы:

· SessionStorage — очищается при закрытии вкладки, не подходит для корзины;

· IndexedDB — избыточно сложен для простых структур данных;

· Cookies — ограниченный размер, отправляются с каждым запросом.