Англійська для розробників Fresh (Deno Framework)

Fresh conversations використовує термінологію «острівців», знайому з Astro, але застосовує специфічні для Fresh типові значення — без кроку збирання, нуль JS за замовчуванням — тому розробник, що приходить з фреймворку з багатою кількістю пакетів, повинен перекалібрувати декілька припущень.

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

Architecture of Islands — модель відтворення Fresh, де сторінки відображаються сервером HTML за замовчуванням, і тільки компоненти, явно позначені як острови, відправляють JavaScript з боку клієнта для інтерактивності. “Смужка пошуку має бути острівцем, оскільки вона має стан клієнта, але тіло статті залишається відтвореним сервером — немає причини для відсилання JS для статичного тексту.”

** Без кроку збирання ** — Fresh обслуговує TypeScript безпосередньо через компіляцію часу виконання Deno, тобто немає окремого етапу збирання або транспіляції між написанням коду і його розгортанням. “Немає кроку збирання для зневадження тут — якщо це працює локально, то це працює в виробництві, тому що Deno компілює той же TypeScript обидва рази.”

** Zero JS за типом ** — початкове припущення, що сторінка Fresh не надсилає жодного JavaScript з боку клієнта, якщо компонент явно не позначено як острів. “Ми відправили всю цю сторінку без JS за замовчуванням — це чистий HTML і CSS, поки комусь не знадобиться інтерактивний калькулятор цін.”

** Часткове ** — функція « Свіже », яка надає змогу перевідобразити розділ сторінки на сервері і обміняти його на DOM без перезавантаження всієї сторінки, для часткових оновлень без важкого клієнта.

• “Використовувати частковий для відфільтрованого списку продуктів — ви отримаєте реактивний вигляд без перетворення всієї сторінки на острів, відтворений клієнтом.” *

** Fresh manifest ** — сформовані файли, що відображають маршрути і острови до їх обробників, відновлюються автоматично під час додавання, вилучення або перейменування файлів.

• “Не редагуйте вручну манифест — його відтворюється зі структури файла, тому виправте файл маршруту і дозвольте Fresh відтворити його.” *

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

• Чи цей компонент дійсно повинен бути островом, або він може залишитися серверним відтворенням?»
• «Оскільки немає жодного кроку збирання, чи відбувається ця помилка під час виконання, чи це помилка типу, яку ми не ловимо до часу запитів?»
• «Чи можемо ми запустити нуль JS за замовчуванням тут, або ж ця сторінка дійсно потребує клієнтської інтерактивності?»
• Чи буде часткова обробка цього оновлення, або нам потрібен повний острів для державного управління?»
• Чи регенерувався манифест після того, як ми перейменували цей маршрутний файл?

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

Зневадження невідповідності гідрування: “Це не працює, тому що ми зробили всю карту островом — якщо ми скоротимо обсяг острова до кнопки, решта залишиться відтвореною сервером, і невідповідність зникне.”

Пояснення вибору архітектури:

• “Ми вибрали Fresh для цього внутрішнього інструмента, оскільки нуль JS за замовчуванням означає, що базові сторінки завантажуються миттєво, і ми платимо лише за JS на двох екранах, які дійсно потребують його.” *

Перегляд запиту на звантаження: “Це не обов’ язково повинен бути повний острів — часткове перевідтворення обробляє фільтрування без надсилання клієнтської бібліотеки стану для одного спадного списку.”

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

• Скажімо ** архітектура островів **, а не “React острови” - підхід Fresh не пов’язаний з React і відмінність має значення при порівнянні фреймворків.
• Підкреслюйте ** нуль JS за замовчуванням **, коли виправдовуєте перемогу продуктивності — це фактичний механізм, а не нечітке «це швидкий фреймворк»
• Розрізняти ** частковий ** від повного острова у дискусіях щодо дизайну — вибір типового острова, коли частковий острів буде достатнім, додає непотрібну вагу стороні клієнта.
• Згадуйте no build step, коли пояснюєте, чому локальна і виробнича поведінка збігаються — це вилучає цілу категорію помилок « працює на моїй машині ».

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

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

Навигація Nuance: професійна комунікація для розробників Deno

Ядро вивчення професійної англійської мови не тільки в тому, щоб знати окремі слова; це про розуміння * як * ці слова використовуються в контексті. Як розробник Deno, особливо працюючи з архітектурою Fresh і її акцентом на нуль-JS типових значень і краю рендерингу, ви будете спілкуватися регулярно - в межах вашої команди, під час перегляду коду, при документації функцій, і навіть в асинхронних розмовах Slack. Часто, тонкі відмінності у фразування можуть значно вплинути на ясність і прийняття. Давайте розглянемо деякі спільні області, де носії англійської мови, які не є рідними, можуть стикатися з викликами і як ефективно підходити до них.

Однією з критичних областей є вираз технічних рішень. Просто сказати «ми використовуємо Deno» недостатньо. Ты должен объяснить, почему ты сделал такой выбор. Наприклад, замість того, щоб сказати «Ми реалізували кінцеву точку API таким чином», більш професійне формулювання буде таким: «Ми вибрали кінцеву точку, засновану на Deno, тому що вона відповідає філософії Fresh щодо мінімізації JavaScript на стороні клієнта і використовує можливості рендерингу краю для поліпшення продуктивності». Аналогічно, коли звертаєтеся до зворотного зв’ язку - особливо в перегляді коду - уникайте фраз на кшталт “Це неправильно.” Замість цього спробуйте: “Я розумію вашу занепокоєність щодо потенційної затримки. Давайте дослідимо стратегії для оптимізації цього маршруту за допомогою використання нативної модульної системи Deno і, можливо, кешування відповідей на краю. ” Це про обрамлення вашої роботи в межах цілей проекту і конструктивне визнання інших перспектив. Зверніть увагу на вираз невизначеності - “Я не впевнений, чи це найефективніший підхід” є набагато більш прийнятним, ніж остаточне твердження при дослідженні альтернатив.

Іншою частою перешкодою є опис змін у запитах на захоплення. Хороший опис PR повинен чітко описувати * що * було змінено, * чому * це було змінено, і * як * це впливає на існуючу функціональність. Не просто перелічуйте рядки коду; поясніть їхню логіку. Наприклад: «Ця PR переробляє логіку автентифікації користувача, щоб поліпшити безпеку і дотримуватися принципів дизайну Fresh zero-JS. Зміни використовують вбудований модуль криптографії Deno для безпечного гешування паролів, зменшуючи залежність від зовнішніх бібліотек і спрощуючи розгортання. » Чиста комунікація є ключем до гладкого процесу перегляду.

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

Ось приклад того, як API fetch Deno може бути використано в описі PR:

# Fetching data from an external API endpoint using Deno's fetch
// This demonstrates the minimal approach to network requests in Deno, aligning with Fresh’s zero-JS philosophy.
const response = await fetch('https://api.example.com/data', { method: 'GET' }); // Use a real API URL for testing
const data = await response.json();
console.log(data);

Цей простий приклад підкреслює основну силу Deno - легкий, рідний підхід до мережі, який ідеально підходить до архітектури Fresh і його прихильності до зменшення залежності від JavaScript.