Ранее мы говорили о том, как Карусель решила проблему разнообразия листинга с помощью нашей системы пользовательского интерфейса. Сиоу Янг, один из инженеров проекта, представил концепцию наборов полей, документов, написанных с использованием специальной разметки Carousell для передачи макета экрана клиентам.

Наборы полей состоят из полей, каждое из которых представлено типом компонента на клиенте. Описание и цена объявления могут быть представлены в виде абзаца, хотя и с разным содержанием. При написании набора полей вы решаете, какие компоненты использовать, каким данным они соответствуют и как расположить поля.

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

JSON, основной продукт веб-сервисов, представляет собой формат обмена текстовыми данными, который очень похож на объект JavaScript. Он удобочитаемый, простой для понимания и очень гибкий, что делает его идеальным для передачи данных.

Однако со временем мы начали сталкиваться с парой проблем, а именно:

  1. Растущее количество документов fieldset для обслуживания.
  2. Изменения в наборах полей проверяются с помощью пользовательских тестов Python, которые не масштабируются и непрозрачны для человека при редактировании набора полей.

Кроме того, мы хотели дать возможность не инженерам создавать наборы полей, сократив время на создание новой категории. Редактирование больших документов JSON может быть сложной задачей и не вселяет уверенности. Мы начали искать решение, которое могло бы быть более удобным, например, форма.

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

Однако создание форм для конкретных компонентов не масштабируется и не переводится на другой язык программирования.

Одним убедительным решением, которое мы в итоге приняли, была схема JSON. Сама схема JSON написана в JSON, декларативном формате, который описывает структуру данных и может использоваться для автоматизации проверки.

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

Работа со схемой JSON позволила нам аннотировать тип, аналогично существующим кодировкам сообщений, которые зависят от схем¹. Кроме того, он поддерживает специальные аннотации для проверки, такие как обязательные свойства, сопоставление с образцом и условная подсхема, что означает, что нам больше не нужны рукописные тесты² для проверки наборов полей.

Но самая сильная особенность схемы JSON в том, что ее общее богатство хорошо подходит для сгенерированных форм³. Затем мы можем сгенерировать формы создания полей, описанные выше, масштабируемым образом.

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

Я надеюсь, что эта статья может послужить источником вдохновения для решения проблем, которые вы решаете. Как всегда, не стесняйтесь обращаться к нам.

Сноски

  1. Мы также рассматриваем сообщения protobuf как способ определения компонентов. Существует множество генераторов как для клиента, так и для сервера, и он также поддерживает требуемые свойства и сопоставление с образцом.
  2. Мы также начали представлять эти компоненты как структуры Go, устраняя необходимость в пользовательской проверке на стороне сервера. Если тело запроса JSON можно неупорядочить, это допустимое поле.
  3. React-jsonschema-form - популярная библиотека. Поддержка свойств, допускающих значение NULL, с использованием нескольких типов "type": ["string", "null"], additionalItems, oneOf, anyOf может быть грубой.