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

Модель Phoenix LiveView — процеси стану сервера, що відсилають відмінності DOM через постійний сокет — не відображається чисто на SPA-лексиконі, який більшість розробників вже знають, тому пояснення вади LiveView вимагає своїх власних термінів. Цей посібник їх охоплює.

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

** Socket ** — постійне з’ єднання WebSocket між клієнтом і процесом LiveView, яке переносить події вгору і відмінності DOM вниз протягом усього часу існування сторінки. “Стан відключення, який ви бачите, означає, що сокет відмовився від зв’ язку — перевірте, чи це мережевий бліп, чи сам процес LiveView зазнав аварії на сервері.”

** Призначає ** — стан збережений на сокеті LiveView (доступ через socket.assigns ), аналогічний стану компонента, оновлюється за допомогою assign/3 і перевідображається при кожній зміні. “Подрахунок не оновлюється у шаблоні, оскільки ми змінили локальну змінну замість виклику assign — LiveView перевідтворює лише тоді, коли змінюється призначення.”

** Diff (DOM patch) ** — мінімальний набір змін, які LiveView обчислює і надсилає клієнту після оновлення стану, замість того, щоб щоразу знову надсилати повний відтворений HTML. “LiveView не пересилає всю сторінку під час кожної події — він обчислює відмінності лише змінених частин і латів існуючого DOM.”

** handle_event ** — зворотній виклик, який отримує події, викликані клієнтом (натискання кнопок, надсилання форм), надіслані через сокет, і повертає оновлений сокет з новими призначеннями. “Кнопка нічого не робить, оскільки атрибут phx-click не відповідає жодній умові в handle_event — перевірте, чи точно відповідає рядок назви події.”

** Процес LiveView ** — процес Erlang/ Elixir на сервері, який має певні призначення LiveView на час з’ єднання, по одному на кожного з’ єднаного клієнта.

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

** Hook (JS hook) ** — невеликий шматочок JavaScript на стороні клієнта, приєднаний до елемента DOM за допомогою phx-hook, використовується для поведінки, яку серверна модель LiveView не може обробляти сама, наприклад, бібліотеку діаграм або доступ до буфера обміну даними.

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

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

• Чи є сокет дійсно під’єднаний, або це питання про «від’єднаний» стан?
• «Чи викликали ми assign тут, чи ми мутуємо карту присвоєнь безпосередньо і очікуємо пере-рендеринга, який не відбудеться?»
• Чи ця подія навіть досягає handle_event, чи є зв’язок phx-click неправильним?
• Чи це на користувача стан живуть правильно в процесі LiveView, або ми випадково зробили його глобальним? ”
• Чи потрібно цьому JS-гачок, чи може LiveView обробляти його з простим diff?

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

Пояснення вади в описі PR: “Лічильник не оновлюється, оскільки логіка приросту змінила карту призначення на місці замість виклику assign/3 — LiveView відстежує зміни за посиланням, тому мутація на місці не викликає перевідтворення.”

Звітування про проблему з сокетом:

• “Користувачі з нестабільними з’ єднаннями бачать застряглий баннер « перез’ єднання » — це схоже на те, що процес LiveView зазнає аварії під час перез’ єднання, а не відновлюється чисто, на основі журналів помилок.” *

Обговорення рішення щодо архітектури: “Ми додаємо JS-гачок для взаємодії перетягування і скидання, а не намагаємося моделювати її повністю на стороні сервера — деякі взаємодії справді клієнт-локальні і не потребують поїздки в обидві сторони.”

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

• Кажуть assigns, а не “state,” коли контекст конкретно LiveView — це термін, який очікують рецензенти і пов’язує безпосередньо з assign/3 семантики, що простий “state” не передає.
• Явно вказувати на стан з’ єднання ** socket ** під час зневадження інтерфейсу користувача, який перестає відповідати — « сторінка заморожена » є набагато менш дієвою, ніж « сокет від’ єднано »
• Проясніть, чи логіка знаходиться в ** LiveView процесі ** або ** JS гачку **, коли обговорюється де функція повинна бути реалізована — це центральне архітектурне рішення в більшості LiveView PR.
• Використовуйте ** diff ** або ** DOM patch **, коли обговорюватиметься швидкодія, оскільки ефективність LiveView залежить від надсилання лише зміненої розмітки, а не відновлення всієї сторінки.

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

1. Поясніть одним реченням, чому зміна присвоєнь безпосередньо не викликає перевідтворення.
2. Написати звіт про помилку з описом сокета, який роз’ єднується і не відновлюється.
3. Опишете вашими словами, коли потрібне прив’ язування JS, а коли простой перегляд LiveView.

Навігація Nuance: професійна англійська для LiveView

Як розробник LiveView, ви не просто пишете код; ви спілкуєтеся. Ви будете описувати свою роботу колегам під час перегляду коду, створювати запити на витягування і співпрацювати у командних каналах. Вміння чітко і точно формулювати технічні концепції є надзвичайно важливим, особливо при роботі з колегами з різних сфер. Багато не-англомовних носіїв англійської вважають швидку еволюцію технологій, таких як LiveView, особливо складною - не тільки через сам синтаксис, але і через спеціалізований словник і фрази, що використовуються в спільноті розробників. Цей розділ присвячено удосконаленню цього спілкування, переходячи від простих визначення до демонстрації нюансового розуміння основних концепцій LiveView. Ми дослідимо, як впевнено і точно висловлювати ідеї, коли обговорюємо такі речі, як «призначення», «різновидності» і «роз’єми».

Однією з найпоширеніших областей, де виникає плутанина, є концепція * керування станом * у LiveView. Не достатньо просто сказати « Я оновив стан ». Замість цього вам слід описати, яким чином було здійснено оновлення, особливо якщо мова йде про асинхронні дії або складні взаємодії між компонентами. Розглянемо сценарій під час перегляду коду. Старший розробник може залишити коментар на вашому PR: « Чи можете ви розібратися, як цей assign справляється з потенційними умовами гонки? Неясно, чи гарантовано, що оновлення стану буде атомарним. ” Це не про критику; це про забезпечення міцної, передбачуваної поведінки. Краще відповідь буде щось на зразок: “Я реалізував assign всередині транзакційного блоку, щоб забезпечити атомарність і запобігти одночасним оновленням. Транзація гарантує, що або вся операція буде успішною або зазнає невдачі, зменшуючи потенційні умови гонки. “Так само, при описі змін в описі PR ви можете сказати: “Це оновлення використовує механізм сокету LiveView для забезпечення майже миттєвого зворотнього зв’ язку до користувача, надсилаючи оновлення даних безпосередньо до їхнього браузера без необхідності повного перезавантаження сторінки. diff є мінімальним і фокусується на поліпшення чутливості форми. ”

Іншим ключовим елементом є розуміння термінології, що оточує * hooks . За допомогою прив’ язок ви можете виконувати код на певних стадіях життєвого циклу LiveView — перед відтворенням, після відтворення або під час події WebSocket. Використання точної мови тут уникає неоднозначності. Замість того, щоб сказати « Я додав гачок », ви можете сказати: « Я реалізував гачок post для обробки перевірки введення користувача * перед надсиланням даних форми ». Таким чином ви чітко вкажете на мету і час виконання гачка. Крім того, розуміння того, що LiveView використовує websockets для оновлення в реальному часі, вимагає ретельного формулювання - опису того, як зміни поширюються і обробляються такими термінами, як «підписка» або «поток подій».

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

# Example: Using `Phoenix.Socket` to send a message
{:ok, socket} = Phoenix.Socket.subscribe("my_channel", user_id: 123)
Phoenix.Socket.send(socket, :push, %{"message" => "Hello from LiveView!"})