Англійська для розробників Sanity CMS
Словник для розробників, які використовують Sanity, платформу структурованого вмісту — схеми, запити GROQ, озеро вмісту і співпрацю в реальному часі — для міжфункціональних команд, що працюють англійською мовою.
Sanity позиціонує себе як «структуровану платформу контенту», а не традиційну CMS — контент зберігається в хостованій базі даних в реальному часі (озеро контенту) і запитується за допомогою власної мови запитів, GROQ. Оскільки Sanity має справді відмінні концепції від типової CMS, і тому що команди контенту і інженери працюють в Sanity Studio щодня, точний англійський словник уникає багато крос-функціональної плутанини. Цей посібник містить умови.
Фундаментальні поняття
** Структурований вміст ** — вміст, що моделюється як дискретні, типовані поля (а не один великий HTML- об’ єкт), отже, один і той же вміст може відображатися по- різному у мережі, мобільному пристрої та інших каналах. “Оскільки наші описи продуктів є структурованим вмістом, а не сирим HTML, ми можемо відтворювати ті ж дані, що і веб-сторінка, екран програми або електронна пошта — без дублювання чого-небудь.”
** Content lake ** — хостований, в реальному часі, склад даних Sanity, де зберігається весь ваш вміст, доступний з будь-якого місця за допомогою API. “Кожна редагування негайно потрапляє в озеро контенту — якщо два редактори мають відкриту студію, вони бачать зміни один одного в реальному часі.”
Sanity Studio — відкритий, налаштовуваний інтерфейс адміністратора, де редактори створюють і керують вмістом; це програма React, яку можна розширити за допомогою нетипових компонентів вводу.
“Ми створили нетиповий компонент вводу у Studio для нашого поля таблиці цін — типовий редактор масиву не надавав редакторам достатньо чіткого перегляду.”
Схема і контент моделювання
Тип схеми
** Тип схеми ** визначає форму документа або об’ єкта — його поля, правила перевірки і те, як він буде показано у Studio.
“Ми визначили новий тип схеми
caseStudyз посиланням на поле назад доclient, тому редактори можуть пов’язати дослідження з правим записом клієнта.”
Document
** Документ ** — це частина вмісту верхнього рівня, яку можна опублікувати незалежно, на зразок статті у блогу або продукту, кожна з яких має свій ідентифікатор і історію редагування.
Reference
Поле ** посилання ** посилається на один документ іншого документа (наприклад, на статтю у блогу, яка посилається на документ автора), зберігаючи вміст документа нормальним, а не дублюючи його.
“Замість переписування біографії автора в кожному пості, ми використовуємо поле посилання, яке вказує на єдиний
authorдокумент — оновлення біографії, як тільки вона оновлюється всюди.”
Портативний текст
** Portable Text ** — це формат багатого тексту, заснований на JSON, розроблений Sanity, призначений для відтворення у будь- якій платформі або каналі, на відміну від HTML, який пов’ язано з мережею.
“Оскільки наш вміст тіла є Portable Text, а не HTML, те саме поле відображається правильно на нашому сайті Next.js, нашому React Native програмі, і наших шаблонах електронної пошти.”
Запитування за допомогою GROQ
** GROQ (Graph- Relational Object Queries) ** — власна мова запиту Sanity, розроблена для фільтрування, з’ єднання і проектування структурованого вмісту у єдиний експресійний запит.
“Запит GROQ об’ єднує запис у блогу з його автором і категорією в одному обхідному шляху — не потрібні окремі виклики API.”
** Проекція ** — частина запиту GROQ, яка визначає, які поля (і вкладені посилання) буде повернено у відповіді.
“Ми скоротили проекцію до лише тих полів, які дійсно відображає домашня сторінка — це значно зменшило розмір корисної інформації.”
** Dataset ** — названий, ізольований екземпляр вашого вмісту (зазвичай production і staging ), який надає вам змогу перевіряти зміни у схемі без втрати реального вмісту.
- “Ми спочатку перевірили нове поле схеми на наборі даних перевірки, а потім перенесли його до виробництва, коли переконались, що нічого не пошкоджено.” *
Редактор і співавтор
** Співпраця у реальному часі ** — декілька редакторів можуть працювати над одним і тим же документом одночасно, бачити курсори і зміни один одного у реальному часі, подібно до спільного редактора документів.
“Двоє авторів редагували одну і ту ж сторінку одночасно, і жоден з них не переписав роботу іншого — Sanity об’єднує зміни в реальному часі.”
** Чернетка і опубліковані стани ** — кожен документ може мати неопубліковану чернетку разом з опублікованою версією, що надає змогу редакторам працювати над змінами без впливу на поточний сайт.
“Чорновий варіант має три нові абзаци, які маркетингова команда все ще переглядає — опублікована версія, яку бачать клієнти, ще не змінилася.”
** Випуск вмісту ** — спосіб групування декількох змін документа разом і опублікування їх всіх одночасно, корисний для скоординованого випуску багатьох частин вмісту.
“Ми об’єднали нову сторінку з цінами, оновлені ЧЗВ і копію банера в одну сторінку, тому вони всі будуть доступні разом о 9 ранку.”
Розповідь про віруючих
| Situation | Phrase |
|---|---|
| Explaining structured content’s value | ”Because the content is structured rather than one HTML blob, we can reuse the same product data across the website, the app, and our marketing emails.” |
| Describing draft/published separation | ”Your changes are saved as a draft immediately, but customers won’t see them until you explicitly publish.” |
| Justifying GROQ over REST | ”One GROQ query gets us the post, its author, and its category together — with REST we’d need three separate round trips.” |
| Explaining real-time collaboration | ”You can both be in the same document at once — Sanity will merge your changes instead of one of you overwriting the other.” |
Поширені помилки
- Виклик Portable Text « просто JSON » — це структурований формат збагаченого тексту з визначеною специфікацією для відтворення, а не довільний JSON.
- Сказати «CMS база даних», коли більш точним терміном Sanity є ** content lake ** — це специфічний, в реальному часі, сховище даних, а не загальна база даних.
- Посилання на будь-який запит контенту як «GraphQL» — рідна мова запиту Sanity — GROQ; GraphQL доступний як окремий, додатковий шар API.
Практичні вправи
- Поясніть двома реченнями, чому структурований вміст дозволяє відтворювати ті ж дані по- різному у різних каналах.
- Написати коротке повідомлення редактору вмісту, у якому буде пояснено відмінність між чернеткою і опублікованим документом.
- Створити коментар перегляду коду, у якому буде запропоновано обмежити проекцію GROQ лише полями, які дійсно використовуються на сторінці.
Зв’язані ресурси
- Англійська для розробників Keystatic CMS
- Англійською мовою: GraphQL Federation
- Англійська для Contentful CMS Developers
Переклади: «Переклад з німецької мови»
Сила Sanity полягає в його здатності полегшити чітке спілкування між різними командами - ключовий елемент, коли справа доходить до різних рівнів володіння рідною англійською мовою. Це не просто знати визначення таких термінів, як «schema» або «GROQ», але розуміти, як вони використовуються в робочому потоці, і, що важливо, як ви будете сформулювати свої наміри для інших. Багато розробників спочатку зосереджуються на прямих перекладах з їхньої першої мови, що може призвести до неоднозначності і непорозумінь. Наприклад, розробник, звиклий до більш багатослівного підходу, може інстинктивно описати складний запит як «відновлення всіх даних, пов’язаних з…», коли коротка фраза, наприклад, «відновлення вмісту з цим запитом GROQ» є набагато ефективнішою в контексті Sanity.
Ключова відмінність часто полягає в очікуваному рівні деталізації і неявному розумінні в команді. У перегляді коду, наприклад, отримання коментаря на кшталт «Цей запит здається неефективним» потребує ретельного розпакування. Це не обов’ язково звинувачення; це може бути справжнім спостереженням про продуктивність або пропозицією щодо оптимізації. Продуктивна відповідь не просто “Все гаразд”, а “Я розглядав використання [альтернативної техніки], щоб поліпшити початковий час завантаження, але я віддав перевагу швидкості, тому що…” - демонструючи розуміння того, * чому * поточний підхід був обраний і визнаючи потенційні проблеми. Аналогічно, в розмовах Slack при обговоренні опису PR, ясність є найважливішою. Неясного опису, наприклад, «Оновлений вміст» недостатньо; замість цього «Вреалізовані зміни схеми для сторінок продукту, включаючи нові зображення і оновлення метаданих за допомогою GROQ» повідомляє точно, що було зроблено і чому це важливо для більшого проекту.
Крім того, активне формулювання — запитання прояснюючих питань, а не припущення розуміння — є безцінним. Замість того, щоб пасивно приймати пропозицію, запитайте: «Чи можете ви розібратися, що ви маєте на увазі під «оптимізацією цього запиту»?» або «Чи можете ви показати мені приклад того, як цей підхід виглядає в GROQ?». Ці невеликі зміни в спілкуванні можуть значно зменшити тертя і поліпшити співпрацю. Не бійтеся ввічливо запитати про контекст; це набагато краще, ніж боротися з немовленими припущеннями.
Ось простий приклад використання інтерфейсу командної рядки Sanity для демонстрації отримання вмісту:
sanity fetch-one --id product/12345Ця команда, коли її пояснюють, є чимось більшим, ніж просто буквальною дією отримання елемента — це доступ до певної частини структурованого вмісту у озері вмісту Sanity на основі його унікального ідентифікатора. Це невеликий фрагмент, але він ілюструє, як навіть здавалося б прості команди потребують чіткої артикуляції і розуміння в рамках більш широкого процесу розробки.