A / B-тестирование для приложения React SSR с чанкингом - PullRequest
Новая
       21

A / B-тестирование для приложения React SSR с чанкингом

1 голос
/ 25 мая 2019

Версии: 

webpack: 4.30.0,
react: 16.8.6,
react-loadable: 5.5.0,

У меня одна запись JS в веб-пакете.Другие чанки в настоящее время создаются с использованием react-loadable, а поставщик JS создается с использованием splitChunks.

Идея моего приложения: SSR и чанкинг работает с react-loadable для компонентов уровня маршрута.И чанк dynamic-components может быть выполнен с использованием либо обещания импорта веб-пакета, либо реакции Loadable.

Теперь я хочу представить A / B-тестирование этих динамических компонентов.

У меня есть 2 подхода:

  1. Первый подход: Обернуть динамический оператор импорта внутри if-иначе импортировать A / B-вариацию этого динамического компонента.И на уровне сервера я бы знал, что для данного пользователя я бы установил флаг в хранилище Redux, чтобы выбрать вариант A / B.(Этот подход можно использовать для определения того, является ли приложение SSR и SPA.)

    Примечания для этого подхода:

    a.Кажется выполнимым: P

    b.Не может масштабироваться для A / B / C очень легко.В этом случае мне нужно было бы ввести третье условие, чтобы динамически импортировать C-вариацию.Это разрушит кеширование браузера для фрагмента компонента уровня маршрута (содержащего эти варианты), потому что хэш в имени файла изменен.И то же самое произойдет со всеми компонентами уровня маршрута, которые вступят в силу для добавления дополнительного тестирования C.

    c.Приходится излишне загрязнять код if-условиями.Если A / B-тестирование завершено, то код снова придется изменить, что снова приводит к перегрузке кэша браузера.

  2. Второй подход: У меня будет только 1динамический импорт в коде, но я хочу 3 разных блока для одного и того же компонента A, B и C, например A/some_chunk[hash].js, B/some_chunk[hash].js и C/some_chunk[hash].js.А на уровне сервера я бы использовал ту же логику для сегментирования пользователя для тестирования A / B / C, что и в подходе 1, но вместо установки флага в хранилище с избыточностью ** я буду обслуживать some_chunk[hash].js от A, B или Cпапка в соответствии с сегментом пользователя.

    Примечания для этого подхода:

    a.Мне нужно спросить, как мы можем создать чанки для динамического компонента без фактического импорта в файл.

    b.Может очень легко масштабироваться для A / B / C-тестирования, поскольку теперь A / B-тестирование теперь зависит от того, какой вариант файлового сервера обслуживает.

    c.Нет загрязнения кода условиями if-else в клиентском коде.Нет проблем с кешем браузера.

    d.Потребуется отдельный компонент-оболочка для серверного кода для ReactDOMServer.renderToString, чтобы узнать, какой вариант выбрать для рендеринга на стороне сервера.

Вопросы:

  1. Итак, мне нужно знать, как мы можем создать чанк согласно второму подходу?Поскольку веб-пакет игнорирует создание порции для файла, если он недоступен (то есть не импортируется каким-либо другим файлом)

  2. Вы бы порекомендовали этот подход.Какой правильный подход приложения микро FE для тестирования AB?

PS:

Если это выполнимо, тогда мой план будет разделяться на частидля базовых макетов, а также.Где я могу избежать условий if-else в коде и всей компоновке, которые могут быть изменены в соответствии с тем, какой сервер вариантов A / B отправляет в браузер.

...