При создании расширения chrome следует ли выполнять вызовы API из фонового сценария или внешнего интерфейса? - PullRequest
Новая
       6

При создании расширения chrome следует ли выполнять вызовы API из фонового сценария или внешнего интерфейса?

0 голосов
/ 18 марта 2020

Я создаю расширение chrome, которое требует вызова API HTTP Get Request при каждой загрузке новой страницы. Затем мое расширение вставляет IFrame на веб-страницу, на которую я хотел бы предоставить данные из вызова API. Я разработал два разных способа сделать это. Мне удалось получить оба способа работы, однако мне интересно, какой из них более целесообразен.

  1. После того, как скрипт содержимого внедряет фрейм, он вызывает фоновый скрипт. В фоновом скрипте мы извлекаем данные и выполняем передачу сообщений с помощью функции postMessage для отправки данных в IFrame. Затем данные принимаются скриптом внутри IFrame, и данные загружаются.

  2. После того, как скрипт содержимого внедряет iframe, скрипт запускается внутри IFrame, который извлекает данные. Затем этот же скрипт загружает данные.

Или, если есть какие-либо другие методы, я был бы признателен за любые рекомендации. Моя логика c на момент сравнения двух описанных мною методов заключается в том, что первый метод имеет преимущества при выполнении вызовов API из сценария backgorund, тогда как второй метод имеет то преимущество, что не требует большого объема связи между различными сценариями. .

Один из этих методов лучше? Спасибо за совет.

1 Ответ

2 голосов
/ 18 марта 2020

Любая страница расширения или фрейм с URL-адресом chrome-extension:// имеют равные права. Он включает в себя фреймы, которые вы вставляете на веб-страницах, когда src указывает на файл html из вашего расширения, который отображается через web_accessible_resources в манифесте. json.

Это означает, что нет внутренние ограничения или предпочтительные методы.
Это зависит только от жизненного цикла данных.

Когда имеет смысл сделать запрос на фоновой странице:

  • для кэширования это в переменной / объекте, если у вас есть постоянная фоновая страница по любой причине;
  • , чтобы избежать прерывания запроса из-за того, что вкладка закрыта или перемещена пользователем или сценарием основного документа;
  • для преобразования данных с использованием некоторой библиотеки, которую вы загружаете в фоновом скрипте и не хотите загружать ее в страницу / фрейм пользовательского интерфейса по любой причине, например, из-за медленной загрузки.
  • по любой другой причине.

Что касается обмена между страницами, то это должно быть быстрым даже при обмене сообщениями, если ваши данные не превышают ограничение размера сообщения в 64 МБ, в этом случае вы пришлось бы использовать Blob URL-адреса или напрямую обращаться к переменной через getBackgroundPage , которая возвращает объект window фонового скрипта. Также имеется BroadcastChannel API, который должен работать между всеми chrome -extension: // страницами или фреймами расширения, а в Chrome он должен быть намного быстрее обмена сообщениями благодаря использованию алгоритм структурированного клонирования вместо JSON stringify / parsing, используемый внутренними сообщениями.

Как правило для любых проблем, связанных с производительностью: используйте профилировщик производительности devtools.

...