Телеметрия, управляемая моделями

Это все еще WIP…

Резюме: Команда, в которой я работаю, приняла решение использовать xState в качестве библиотеки управления состояниями. Парадигма машины состояний хорошо сочетается с нашим приложением или любой моделью данных Prev ↔︎ Next.

Интересным преимуществом моделирования состояния приложения с помощью xState является возможность тесно связать события и телеметрию приложения, или регистрацию/отслеживание/отчетность по этим событиям. Кроме того, благодаря визуальному представлению машины состояний — то, что xState предоставляет «из коробки» — мы можем легко увидеть все места в нашем приложении, где у нас есть телеметрия.

Фон

.

«Единственное, что должно происходить внутри слушателей событий — это отправка события»

— Дэвид Хуршид, автор xState

Один из многих паттернов, который вносит значительный вклад в ментальное перемещение нашей кодовой базы, — это замусоривание ее произвольными вызовами логирования. Иногда мы запускаем эти вызовы внутри обработчиков событий клика…

onClickHandler = async () => {
    try {
        setErrorMessage('')
        Bugsnag.leaveBreadcrumb('Auth.resendSignUp', undefined, 'request')

…где им не место.

Все, что происходит в результате работы кода пользовательского интерфейса, должно быть передано тем частям вашего приложения, у которых есть «мозги». В данном случае это состояние. В xState:

pauseButton.onClick = (e: MouseEvent) => {
  xStateService.send({ type: 'PAUSE' })
}

Иногда вызовы выполняются на основе встроенных условий, и это еще больше запутывает ситуацию:

 const onClick = (isLoading) {     
    if (isLoading)... Analytics.record.  

Иногда они вызываются из «вышестоящих» мест (код с бизнес-логикой) или из «помощников» (утилиты). Эта техника «рассыпания» очень запутанна и приводит к избыточности и плохому покрытию. Можно встретить случаи, когда есть несколько обращений к Braze, Pinpoint и т.д. для одного и того же: пользователь нажимает на кнопку, чтобы отправить форму, поэтому в обработчике клика мы отправляем Pinpoint, что пользователь пытается зарегистрироваться, и вот данные формы как часть полезной нагрузки. Далее, при вызове API, мы отправляем в Pinpoint, что пользователь пытается зарегистрироваться, и вот JSON-тело POST — то же самое содержимое, которое мы только что отправили из пользовательского интерфейса. Я полагаю, что некоторые из этих сторонних организаций ограничивают скорость? Даже если они этого не делают, мы вполне можем в будущем сотрудничать с тем, кто это делает, а это лишние расходы.

Другим распространенным нарушением является ведение журнала через useEffect, что приводит к 11 useEffects, существующих в одном компоненте, потому что, ну, у нас есть 11 вещей, которые нужно отслеживать/заносить в журнал. (Намеренно избегая на данный момент навязанного Next.js требования утверждать, где выполняется код).

useEffect(() => {
    Bugsnag.leaveBreadcrumb('post-verification target', state, 'state')
    void Analytics.record({
        name: PostVerificationAnalyticsIds.ACTION_TARGET_REPORT,
        attributes: state,
    })
}, [state])

Все это очень затрудняет рассуждения о том, что и в каком порядке происходит внутри компонента (случай с чрезмерным использованием useEffect по какой-либо причине).

Последнее и, возможно, самое важное, на что следует обратить внимание, это то, что размещение наших вызовов протоколирования (Telemetry) таким образом дает очень слабую уверенность в том, что мы действительно имеем правильное представление о здоровье и эффективности приложения Enroll.

Возможный ответ?

Мы можем значительно повысить уверенность в телеметрии, собрав всю нашу телеметрию «в одной комнате», чтобы с первого взгляда видеть, что и когда мы фиксируем. Вместо того чтобы (буквально) прослеживать путь события DOM, чтобы увидеть, что мы фиксируем, что если бы мы могли посмотреть на визуальное представление состояния приложения и увидеть, что «о да, мы это закрываем». Оказывается, можно!

Телеметрия на основе событий

Документация xState намекает на идею сосредоточения телеметрии вокруг состояния приложения, хотя и не раскрывает формального обсуждения этой идеи. Точнее, вокруг событий, которые определяют это состояние. Это имеет смысл, если подумать. Нам совершенно наплевать на то, что мы ввели вызов какой-то функции. Зачем нам это записывать? Ошибки нужно отлавливать, эффективность пользовательского интерфейса нужно записывать, но если говорить о том, чтобы проследить, как пользователь нашего приложения проходит весь процесс, мы должны делать это с точки зрения пользовательского опыта, а это означает связь телеметрии с событиями и состоянием.

Реализация

Для исследования в Enroll 1.5 я изложил это следующим образом. xState…