SuperOleg dev notes

Следующий кейс связан с переходом на async скрипты - https://www.tgoop.com/super_oleg_dev/133

Используя defer скрипты, у вас есть уверенность - они будут выполнены когда DOM завершён (безопасно для гидрации) и по порядку.

Первое что я пропустил - это async для скрипта с полифиллами.

Трамвай использует подход с динамической загрузкой чанка с полифиллами - https://philipwalton.com/articles/loading-polyfills-only-when-needed/

При переходе на async мы больше не уверены что полифиллы будут загружены до выполнения основного кода.

Пришлось убрать атрибут defer у скрипта, что неизбежно приведет к штрафу на перформанс, из-за блокирующей загрузки. Ищу идеи получше)

Вторая проблема связана с нашими микрофронтами Child Apps.

Если в скриптах приложения сборщик отвечает за порядок их выполнения, проблем нет даже с async скриптами, так как есть явная связь, например через webpack_require.

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

На клиенте скрипт микрофронта сохраняет его в window в уникальную переменную.

И клиентский код инициализации ожидает наличие этого микрофонта в window, так как скрипт есть на странице - ведь с defer он был бы точно выполнен заранее.

Для решения проблемы пришлось добавить логику ожидания загрузки скрипта - точки входа микрофронта, на события load и error.

И при этом предусмотреть кейс когда он был загружен или упал до навешивания обработчиков этих событий - добавить атрибут loaded, и его проставление true/false инлайн в атрибутах onload/onerror - у тега script нет никакого свойства что бы узнать текущее состояние загрузки скрипта.

При этом архитектурно не должно было поменяться поведение, что догрузка микрофронта на клиенте не должна задерживать инициализацию и гидрацию приложения - как с кейсами для Child Apps которые упали на сервере или их забыли предзагрузить.

Suspense + Error Boundary позволяет показать фаллбэк в каждом проблемном кейсе до итоговой успешной загрузки микрофронта.

Telegram

SuperOleg dev notes

Теперь фреймворк умеет в потоковый рендеринг, появились deferred экшены, и Await компонент для использования этих экшенов вместе с Suspense.

Большая часть работы сделана, проблемы как всегда в деталях.

Тут очередная хвала React Working Group, а именно гайду…

🤔4👍2

www.tgoop.com/super_oleg_dev/166

1.02K viewsedited  Apr 13, 2024 at 10:33

Следующий кейс связан с переходом на async скрипты - https://www.tgoop.com/super_oleg_dev/133

Используя defer скрипты, у вас есть уверенность - они будут выполнены когда DOM завершён (безопасно для гидрации) и по порядку.

Первое что я пропустил - это async для скрипта с полифиллами.

Трамвай использует подход с динамической загрузкой чанка с полифиллами - https://philipwalton.com/articles/loading-polyfills-only-when-needed/

При переходе на async мы больше не уверены что полифиллы будут загружены до выполнения основного кода.

Пришлось убрать атрибут defer у скрипта, что неизбежно приведет к штрафу на перформанс, из-за блокирующей загрузки. Ищу идеи получше)

Вторая проблема связана с нашими микрофронтами Child Apps.

Если в скриптах приложения сборщик отвечает за порядок их выполнения, проблем нет даже с async скриптами, так как есть явная связь, например через webpack_require.

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

На клиенте скрипт микрофронта сохраняет его в window в уникальную переменную.

И клиентский код инициализации ожидает наличие этого микрофонта в window, так как скрипт есть на странице - ведь с defer он был бы точно выполнен заранее.

Для решения проблемы пришлось добавить логику ожидания загрузки скрипта - точки входа микрофронта, на события load и error.

И при этом предусмотреть кейс когда он был загружен или упал до навешивания обработчиков этих событий - добавить атрибут loaded, и его проставление true/false инлайн в атрибутах onload/onerror - у тега script нет никакого свойства что бы узнать текущее состояние загрузки скрипта.

При этом архитектурно не должно было поменяться поведение, что догрузка микрофронта на клиенте не должна задерживать инициализацию и гидрацию приложения - как с кейсами для Child Apps которые упали на сервере или их забыли предзагрузить.

Suspense + Error Boundary позволяет показать фаллбэк в каждом проблемном кейсе до итоговой успешной загрузки микрофронта.

BY SuperOleg dev notes