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

Написання додатка Vite означає роботу з інтерфейсом додатка Rollup плюс спеціальними гачками Vite, які розташовані зверху, а також словниковий запас для опису місця у цьому конвеєрі, де знаходиться вада, має велике значення, коли ви просите допомоги або переглядаєте код додатка когось іншого. Цей посібник містить умови.

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

** Hook ** — названа функція ( resolveId, load, transform, configureServer ), яку Vite викликає у певній точці конвеєра збирання або розробки, утворюючи основний механізм розширення для додатків. “Гак transform — це місце, де ви переписуєте початковий код файла — resolveId тільки вирішує, який файл завантажити, він не торкається вмісту.”

** transform hook** — гачок, який отримує початковий код модуля і повертає змінений код, найпоширеніший спосіб введення або переписування логіки додатками.

• “Наш додаток SVG- to- component виконує свою справжню роботу у гачку transform, перетворюючи необроблену розмітку SVG на рядок компонента Vue.” *

** Режим розробки проти режиму збирання ** — два режими роботи Vite, у яких додаток може поводитися по- різному, оскільки режим розробки обслуговує модулі за запитом за допомогою власного ESM, а режим збирання збирає все у пакет з Rollup. “Цей додаток працює у режимі розробки, але порушує виробничу збірку — перевірте, чи обумовлено гачок на apply: 'serve', коли він повинен працювати в обох режимах.”

** Упорядкування додатків ( enforce ) ** — параметр enforce: 'pre' | 'post', який керує тим, чи виконуватиметься запуск гачків додатка перед або після перетворень ядра Vite, що є критичним, коли додаткам потрібно бачити сирий або повністю перетворений код. “Встановити enforce: 'pre' на цей додаток — йому потрібно побачити оригінальний код TypeScript, перш ніж власне перетворення Vite знищить типи.”

** Віртуальний модуль ** — модуль, який не існує на диску, але створюється додатком під час запитів, ідентифікується спеціальним розв’ язаним ідентифікатором (часто з префіксом \0 ). “Ми виставляємо сформований маршрутний манифест як віртуальний модуль, virtual:routes, щоб компоненти могли імпортувати його без існування реального файла.”

** HMR (Hot Module Replacement) API ** — доступний додаткам API ( configureServer, handleHotUpdate ) для налаштування того, як сформовані або перетворені додатком модулі оновлюються під час розробки без повного перезавантаження. “Без нетипового handleHotUpdate, редагування файла налаштувань викликає перезавантаження всієї сторінки замість простого повторного запуску генератора віртуального модуля.”

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

• «Який гачок ця логіка насправді працює в — resolveId, load, або transform? »
• «Чи потрібно цьому плагіну enforce: 'pre', щоб побачити код перед тим, як інші плагіни перетворять його?»
• «Це віртуальний модуль, чи це розв’язування до реального файлу на диску?»
• Чи це поводиться так само в dev і build режимах, або є гілка, яка відсутня в конкретному режимі?
• Чи є оновлення HMR насправді обмежене зміненим модулем, або це змушує повне перезавантаження?

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

Пояснення помилки додатка у PR: “Перетворення не було застосовано, тому що наш додаток запустився після того, як вбудований у Vite обробник TypeScript вже скомпільував файл — додавання enforce: 'pre' виправило порядок.”

Звітування про розбіжність між розробкою та збиранням: “Це працює добре з vite dev, але виробляє пошкоджений вивід з vite build, що свідчить про те, що гачок load додатка має шлях коду, який працює правильно тільки під графіком модуля Rollup.”

Обговорення віртуального дизайну модуля: “Я краще виставлю цей файл як віртуальний модуль, ніж записую сформований файл на диск — це уникне забруднення репозиторію артефактами збирання і збереже джерело правди у додатку.”

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

• Назвіть точний ** hook **, який використовується під час повідомлення про ваду додатка — « the plugin doesn’ t work » не дає переглядачеві нічого, що можна було б шукати у коді додатка.
• Перевірте ** enforce ordering** перед тим, як припустити, що помилка є в вашій логіці перетворення — багато помилок типу «мій регістр не збігається» насправді є «інший плагін вже перетворив код до того часу, як mine запустився»
• Розрізняти dev mode і build mode у звітах про вади, оскільки сервер розробки Vite і збирувач пакетів Rollup використовують зовсім різні шляхи коду через додаток.
• Використовуйте ** віртуальний модуль ** точно — це стосується певної конвенції роздільності, а не просто « модуль, який динамічно генерується » у вільному сенсі.

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

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

На практиці: Навігація Nuance в комунікації з плагінами

Як розробник, особливо при роботі над інструментами, такими як додатки Vite, які часто включають співпрацю з більшими командами, точне спілкування є абсолютно важливим. Це не просто про те, щоб передати * що * ви зробили, але * як * ви зробили це, і обґрунтування за вашими рішеннями. Ось тут освоєння професійного словника англійської мови піднімає вашу роботу за межі просто функціонального коду до справді ефективного вкладу. Розглянемо кілька реалістичних сценаріїв, які підкреслюють це.

Уявіть, що ви отримуєте коментар про перегляд коду на PR, пов’язаний з модифікацією конвеєра Vite transform для модулів CSS. Рецензент пише: «Ця зміна вводить потенційні вузли продуктивності. Чи могли б ви розкрити логіку використання цього конкретного перетворення і чи розглядалися альтернативні підходи? Просто сказати « Я використовував це перетворення » недостатньо. Більш відшліфована відповідь підтверджує зворотний зв’язок, демонструє розуміння проблеми («Я визнаю, що агресивні перетворення можуть вплинути на часи збирання»), і чітко сформулює ваші аргументи («Це конкретне перетворення було обрано, тому що воно пропонує баланс між оптимальним роздільною здатністю специфічності CSS і мінімальними витратами на продуктивність на основі наших внутрішніх еталонів — див. долучену документацію»). Зауважте використання таких фраз, як «потенційно вузькі місця», «обґрунтування», «альтернативні підходи» і «внутрішні еталони» - це поширені терміни в технічних дискусіях. Аналогічно, коли ви описуєте функціональність вашого додатка у описі PR, ви можете написати: « Цей додаток покращує можливості заміни модулів у режимі очікування (HMR) Vite за допомогою використання нетипового гачка для перехоплення і оптимізації завантаження активів під час режиму розробки. » Ключовим є використання термінології, яка відповідає більш широкій спільноті розробників і чітко пояснює * чому * ця оптимізація має значення.

Інша поширена ситуація виникає в розмовах Slack, де обговорюється порядок замовлення додатків. Можливо, один з колег запитає вас: « Чому мій додаток з’ являється так пізно у процесі збирання? » Зрозуміти концепцію « режиму розробки проти режиму збирання » має вирішальне значення. Додатки поводяться по- різному, залежно від того, чи ви активно розробляєте і оновлюєте вашу програму, чи ж збираєте її для виробництва. Додатки, розроблені в основному для розробки, часто використовують гачки, які запускаються під час HMR, в той час як додатки, призначені для оптимізованих збірок, можуть працювати в рамках окремого конвеєра трансформації. Вміння точно описати це відмінність — « Цей гачок дозволяє мені перехоплювати завантаження активів * тільки * в режимі розробки, запобігаючи небажаній обробці під час збирання » — демонструє складне розуміння архітектури Vite і наслідків дизайну вашого додатка.

Нарешті, розгляньте можливість створення короткого пояснення для молодшого розробника: «vite-plugin-ts-loader використовує певну конфігурацію, щоб забезпечити обробку файлів TypeScript з правильним завантажувачем модулів - важливо зрозуміти, як це взаємодіє з процесом збирання Vite». Чиста і точна мова уникає двозначності і полегшує передачу знань.

Ось приклад того, як ви можете скористатися vite для перевірки порядку додавань:

vite --config vite.config.js plugins

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