Англійська для розробників RedwoodJS

Розмови RedwoodJS часто потребують обґрунтування його думки, повної структури стека і його GraphQL-першого шару даних, тому словник включає клітини, API / веб-розділення і конвенції, які роблять програму Redwood передбачуваною для навігації.

Ключовий словник

** Cell ** — шаблон компонента RedwoodJS, який декларативно обробляє стани завантаження, помилки, порожнечі і успіху запиту GraphQL, вилучаючи вручну керування станом для отримання даних.

• “Замість написання власних гілок завантаження і помилок, оберніть цей компонент у комірку — Redwood автоматично створює всі чотири стани з запиту.” *

api side / web side — розділення RedwoodJS одного монорепо на бекенд GraphQL API пакунок і фронтенд React пакунок, спільні типи, але розгортання незалежно.

• “Логіка перевірки належить стороні API, а не веб- стороні — веб- сторона повинна відтворювати лише те, що API вже перевірив.” *

** SDL (Schema Definition Language) ** — файли схем GraphQL у проекті Redwood, які визначають типи, запити і мутації, які Redwood використовує для автоматичного створення заголовків розв’ язувачів. “Спочатку додайте нове поле до SDL — Redwood буде скаржитися на відсутність розв’ язувача, поки функція служби не відповідатиме тому, що там оголошено.”

Service function — рівень бізнес-логіки в RedwoodJS, який реалізує розв’язувачі, оголошені в SDL, зазвичай містить фактичні виклики бази даних через Prisma. “Зберігайте функцію служби тонкою і перенесіть складну логіку запиту в окремий помічник — простіше проводити тестування блоків поза контекстом GraphQL.”

** Генератори Redwood ** — команди CLI- скелетування ( yarn redwood generate ), які створюють комірки, сторінки, SDL і служби з послідовною структурою файлів і назв. “Просто використовуйте для цього генератори Redwood — написання вручну схеми комірки не варте того, коли генератор виробляє ті ж чотири стани правильно кожен раз.”

Звичайні фрази

• Чи повинна це бути комірка, чи дані досить прості, щоб простий компонент з useQuery був в порядку?
• «Чи має ця логіка жити на стороні API, або вона витікає на веб-сторінку, де вона не належить?»
• «Чи ми оновили SDL перед написанням резольвера, або це тому, що генератор не працює?»
• «Чи робить функція сервісу занадто багато тут, або це все ще розумно для одного резолютора?»
• Чи можемо ми просто зафіксувати це з генераторами Redwood замість копіювання існуючої клітини вручну?

Приклади висловлювань

Пояснення архітектури новопризначеному:

• “Все, що знаходиться під api/, є частиною API — це бази даних і логіка бізнесу. Все під web/ є веб-сторінкою — вона повинна тільки споживати GraphQL, ніколи не розмовляти з Prisma безпосередньо.”*

Перегляд запиту на звантаження:

• « Цей компонент вручну керує завантаженням і станом помилки — чи можемо ми перетворити його на комірку, щоб Redwood обробляв це послідовно з іншими компонентами програми? » *

Включення когось до потоку роботи: “Не пишіть розв’ язувач з нуля — запустіть генератор Redwood для служби, а потім заповніть логіку запиту.”

Професійні поради

• Використовуйте ** cell ** точно в перегляді коду — позначення стану завантаження, яким керується вручну, як « це має бути комірка » є чітким, дієвим коментарем.
• Поясніть розділення ** API- сторони / веб- сторони ** на початку, оскільки розробники, які працюють з фреймворками з одним пакунком, зазвичай використовують безпосередній доступ до бази даних з пакунка інтерфейсу.
• Тримайте обговорення ** SDL ** пов’ язані з мовою «контракт-перший» — це джерело істини, яке розв’ язувач повинен збігатися, що допомагає пояснити помилки генератора.
• Відкинути роздуті ** функції служби ** у перегляді запитанням, чи може логіка перейти до спільної бібліотеки, зберігаючи розв’ язувачі, які можна перевірити в ізоляції.

Практичні вправи

1. Пояснити, що таке комірка і яку проблему вона вирішує у порівнянні з вручну записаними станами завантаження і помилок.
2. Описати відмінність між API і веб- стороною проекту Redwood.
3. Написати коментар перегляду коду з проханням до співробітника команди пересунути блок логіки бізнесу з компонента до функції служби.

На практиці: Навігація нюансів в спільному розвитку

Багато розробників, які вивчають професійну англійську, особливо ті, що переходять з менш формальних контекстів, стикаються з тонкими відмінностями у фразуваннях, що можуть значно вплинути на спілкування в команді розробників. Це не просто про знання слів для «бази даних» або «API»; це про розуміння того, як ці слова використовуються для вираження намірів, конструктивної критики і ефективної співпраці над складними проектами, такими як розгортання RedwoodJS. Розгляньте це: простий запит на зміни може бути сформулований як «виправити цю помилку» - цілком прийнятний у звичайній розмові, але потенційно нечіткий і не корисний під час перегляду коду. Професійнішим підходом буде « Я помітив проблему з логікою перевірки даних всередині комірки user-profile; чи можете ви дослідити, чи поточне реалізування правильно обробляє крайові випадки, пов’ язані з порожніми рядками? » Різниця полягає в специфікі, зосереджуючись на * що * потрібно розв’ язати і * чому *.

Аналогічно, канали Slack, присвячені розробці RedwoodJS, багаті нюансованим спілкуванням. Отримання повідомлення на зразок « Це пошкоджено » не надає багато корисної інформації. Краще відповідь - оформлена як запитання - буде: “Чи можете ви описати спостережувану поведінку? Які дії ви зробили, перш ніж зіткнутися з цією проблемою? Надання контексту допомагає нам діагностувати кореневу причину набагато швидше.» Крім того, під час написання описів запитів на завантаження, важливо вказати, * чому * ви робите зміни. Не просто вкажіть « Впроваджено нову функцію ». Замість цього поясніть причину: « Ця публікація вводить нову кінцеву точку для отримання профілів користувачів за допомогою запитів GraphQL, відповідає дизайну API, описаному у специфікації, і покращує ефективність отримання даних ». Ці, на перший погляд, невеличкі зміни у формулюванні сприяють більш продуктивному і менш розчаровуючим середовищам розробки. Метою є ясність, точність і демонстрація розуміння більш широкої архітектури системи.

Ключ полягає в тому, щоб прийняти активний підхід до документації і комунікації. Якщо ви не впевнені щодо терміну або процесу, завжди запитуйте про пояснення. Не вагайтеся запитати приклади або пояснення. Більшість розробників RedwoodJS раді ділитися своїми знаннями і допомагати іншим розуміти складності фрейму. Пам’ятайте, що професійна англійська не є надто формальною; вона стосується ефективного передачі інформації і будівництва міцних робочих відносин у вашій команді. Це про демонстрацію компетентності, повагу до колег, і зобов’язання до постачання високоякісного коду.

Ось приклад використання redwood develop для запуску локального сервера розробки:

redwood dev

За допомогою цієї команди можна запустити середовище розробки RedwoodJS, яке надає вам змогу взаємодіяти з вашою програмою локально під час розробки, зневадження і тестування. У виводі буде надано інформацію про запущений сервер, зокрема адресу URL і всі відповідні журнали. Це фундаментальний крок у процесі створення і ітерації ваших програм RedwoodJS.