На этой неделе GSoC мы рассмотрим некоторые модификации API, которые мы вносим для поддержки нашего приложения. Мы также видим, что наше приложение наконец обретает форму.

Наконец, я могу с гордостью сказать, что на этой неделе мы достигли многого. Мы раскрыли новые факты и предостережения о нашем существующем API; построил наш сервис для выполнения вызовов REST; сопоставили наши извлеченные данные; обнаружил совершенно новую конечную точку (😎); изменили наш API, чтобы он возвращал более тонкие JSON, и, наконец, у нас есть осязаемый пользовательский интерфейс для загрузки. Фу! Давайте начнем!

Разгадка API модуля Patient Flags

Модуль Patient Flags в основном состоит из двух компонентов — пользовательского интерфейса и API. API делает всю нашу тяжелую работу, включая фиксации в базе данных, обработку бизнес-логики и т. д. Пользовательский интерфейс «общается» с API через набор параметризованных URI, известных как «конечные точки». Эти конечные точки помогают нам отправлять (POST) и получать (GET) данные в API и из него. Вот несколько вещей, которые нужно знать о нашем API:

  1. API был RESTифицирован в ветви omrs2msf Маймуной К. и командой. Однако эта ветвь еще не объединена с мастером.
  2. Мы продублировали эту ветку как 3.2.0 (наша релизная версия) и планируем объединить ее с мастером после того, как зафиксируем в ней OWA.
  3. Конечные точки для REST API задокументированы здесь.

При проверке конечных точек для компонента «Тег» пациента мы заметили несколько вещей.

Уменьшение возвращаемых JSON

Мы используем конечную точку —

 /ws/rest/v1/patientflags/tag

чтобы получить список всех тегов в системе. Каждый «тег» имеет 4 основных свойства — tagId, displayName, visibleTo (кто все может видеть флаг, связанный с тегом) и displayPoints (в каком месте виден флаг, например, «Заголовок пациента»)

Мы заметили, что эта конечная точка в представлениях по умолчанию или ref (представление OpenMRS REST) ​​возвращает файл JSON длиной ~2500 *n строк, где n представляет количество тегов в системе. Это тяжелая (и ненужная) сеть и накладные расходы на синтаксический анализ. Поэтому нам нужно уменьшить этот файл.

Для этого мы модифицируем класс PatientFlagTagResource в API и заставим его возвращать только имена и uuid ролей и displayPoints, когда пользовательский интерфейс запрашивает представление по умолчанию. Это сократило возвращаемые JSON до ~64*n строк. Значительное улучшение.

Обнаружение новой конечной точки 😎

Модальное окно редактирования тега появляется, когда пользователь хочет добавить новый тег или обновить существующий. Это позволяет пользователю выбирать, кому будет виден тег (роли) и где будут отображаться теги (точки отображения).

Список ролей получается путем выполнения метода GET на следующей конечной точке OpenMRS REST API:

GET /ws/rest/v1/role

Но откуда мы получаем Display Points? Оказывается, существует ресурс под названием PatientFlagDisplayPoint, который ранее не был задокументирован. Мы просто звоним —

GET /ws/rest/v1/patientflags/displaypoint

И бац, успехов! «Точка отображения» теперь включена в документы модуля «Флажки пациента».

Завершение спринта №1 и закрепление фундамента в спринте №2

Ретроспектива Agile

В конце спринта №1 мы провели ретроспективу Agile, чтобы ответить на 3 основных вопроса:

  1. Чего мы достигли?
  2. Что пошло не так?
  3. Где мы можем улучшить?

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

Вот три вещи, которые мы узнали

  1. Наше достижение — ощутимый пользовательский интерфейс

Мы использовали прошедшую неделю в качестве буфера для Спринта № 1 — чтобы очистить все TODO Спринта № 1 и заложить основу для приложения — мальчик, это окупилось! Теперь у нас есть осязаемый пользовательский интерфейс, базовый MVP, который воплощает в себе наши стремления от этого проекта.

⚠️ Обратите внимание: мы еще не стилизовали элементы пользовательского интерфейса. Мы также не включили openmrs-react-components. Это должно быть выполнено на Этапе 2 [запланировано].

  1. Ряд вкладок с возможностью навигации [TODO: Маршрутизация для поддержки асинхронной загрузки]
  2. Кнопка «Добавить тег» — открывает модальное окно «Редактировать тег» в режиме «Создать новый», позволяя пользователю создать новый тег.
  3. Представление таблицы. Этот элемент таблицы, реализованный с помощью «реагировать-таблица», является очень универсальным и многофункциональным. Обязательно с моей стороны для реализации таблиц в реакции.
  4. UUID – это тестовый столбец, показывающий, что служба API правильно извлекает данные из серверной части.
  5. Имя тега — при нажатии на имя тега модальное окно «Редактировать тег» открывается в режиме «Редактировать существующий», а имя тега и данные UUID передаются из компонента тега (родительского) в компонент редактирования. Пометьте (дочерний) компонент как реквизит.

😄 Совет.Данные также передаются из дочернего компонента, тега редактирования, в родительский. Для этого можно использовать обратный вызов (подробнее)

6. Кнопка «Удалить» — удаляет данные из таблицы и запускает конечную точку DELETE, используя UUID тега.

2. Представляем ежедневные стендапы

Ну не совсем 😛. Вместо этого мы вводим «псевдоежедневную стойку», при которой ежедневные отчеты о работе регистрируются в ветке Sprint #2, и если возникают какие-либо блокировщики, для решения проблемы могут быть проведены дополнительные сеансы Skype.

Мы столкнулись с множеством неожиданных сюрпризов и проблем в Спринте №1, и для того, чтобы решить их быстрее, мы ожидаем, что ежедневный стендап будет более эффективной мерой.

3. Сокращение продолжительности спринта

Две недели оказались слишком громоздкими. Для этого проекта мы хотим быстро сломаться и быстро научиться, а не ковылять, как слон.

Следовательно, продолжительность спринта теперь была сокращена до 1 недели вместо двух, при сохранении более конкретных и целенаправленных целей.

На этой неделе все!

ССЫЛКИ: