@prisma-cms/module-boilerplate

  1. Статус
    Задача
    Дата создания
    Планируемая дата начала
    Планируемая дата выполнения
    Дата начала
    Дата выполнения
    Постановщик
    Кто работает
  2. Завершена
    25 дек. 2018 г., 4:12
  3. Завершена
    25 дек. 2018 г., 3:53
  4. Завершена
    25 дек. 2018 г., 3:52
  5. Завершена
    25 дек. 2018 г., 3:52
  6. Завершена
    25 дек. 2018 г., 1:20
  7. Завершена
    24 дек. 2018 г., 0:42
  8. Завершена
    24 дек. 2018 г., 0:41
  9. Завершена
    24 дек. 2018 г., 0:41
  10. Завершена
    24 дек. 2018 г., 0:41
  11. Новая
    24 дек. 2018 г., 0:23
  12. Завершена
    24 дек. 2018 г., 0:23
  13. Выполняется

    Задача: Переосмыслить сборку API-схемы

    Проект: @prisma-cms/module-boilerplate

    Предполагалось, что каждый модуль в отдельности сможет влиять на получаемую API-схему путем изменения готовой схемы на уровне метода getApiSchema().
    Но проблема в том, что сейчас в модуле прописана генерация API на основе получаемой базовой схемы призмы. Здесь используется относительный путь для файла схемы. То есть если на конечном проекте будет использоваться более одного призма-модуля, каждый из них будет в отдельности получать такую базовую схему и перетирать имеющуюся схему.

    Но если просто сделать путь абсолютный, то проблема недостаточно решается, потому что на конечном проекте без получения базовой призма-схемы не будут сгенерированы все основные API-методы. Вручную их переписывать тоже не круто.

    Придется делать в два этапа:
    1. Сейчас сделать все-таки относительные пути, чтобы на конечном проекте не перетирались схемы. На конечном проекте все равно придется получить базовую схему и донастроить все необходимые чистки схемы, но плюс в том, что можно будет сделать один базовый компонент для сборки и чистки частоиспользуемой схемы, а поверх уже лепить свое. Это будет довольно полезно для проектов, создаваемых на базе других крупных проектов, чтобы не приходилось вновь чистить все схемы.
    2. Все-таки переписать класс модуля так, чтобы методы компонентов суммировались и в итоге выполнялись общим потоком, а не как сейчас, что каждый модуль выполняется самостоятельно, и только суммируются результирующие схемы, полученные от каждого из этих модулей.
    24 дек. 2018 г., 0:13