Переход с дополнительных действий пользователя и элементов меню ECB на расширения SharePoint Framework
SharePoint Framework (SPFx) — это рекомендуемая модель разработки для расширения и создания настроек SharePoint. Если вы настроили SharePoint с пользовательскими действиями и настраиваемыми элементами меню Изменение блока управления (ECB) с помощью SharePoint Feature Framework, вы можете задаться вопросом, в чем преимущество их миграции в SPFx?
Сначала давайте представим доступные варианты при разработке расширений SharePoint Framework (SPFx):
- Настройщик приложений. Расширьте встроенный "современный" пользовательский интерфейс SharePoint, добавив пользовательские элементы HTML и клиентский код в заранее определенные заполнители на "современных" страницах. Дополнительные сведения о настройщиках приложений см. в разделе Создание первого расширения SharePoint Framework (Hello World, часть 1)
- Набор команд. Добавление настраиваемых элементов меню ECB или кнопок на панель команд представления списка для списка или библиотеки. С этими командами можно связать любое действие на стороне клиента. Дополнительные сведения о наборах команд см. в разделе Создание первого расширения набора команд ListView.
- Настройщик полей. Настройте отображение поля в представлении списка, используя настраиваемые элементы HTML и клиентский код. Дополнительные сведения о настройщиках полей см. в разделе Создание первого расширения настройщика полей.
Выбор варианта зависит от цели настройки. Например, настройщики заполнителей могут заменить собой дополнительные действия пользователя. Наборы команд являются подходящей заменой для элементов меню ECB. Наконец, настройщики полей предназначены для замены настроек JSLink/Client-Side-Rendering (CSR).
Преимущества переноса существующих настроек SharePoint Feature Framework на SharePoint Framework
При создании SharePoint Framework учитывались новые "современные" возможности SharePoint, доступные на "современных" сайтах групп и сайтах для общения, на любом устройстве и любой платформе.
Только поддерживаемый способ настройки "современных" сайтов без скриптов
Одним из основных преимуществ переноса устаревших настроек SharePoint Feature Framework в SharePoint Framework является то, что это единственный поддерживаемый метод настройки пользовательского интерфейса на современных сайтах.
На самом деле на "современных" сайтах включен флаг без скриптов, что позволяет избежать выполнения скриптов, встроенных в страницу, и любых пользовательских действий, которые относятся к внешнему JavaScript или встроенному JavaScript.
Пользовательские действия прежних версий просто не работают в "современном" пользовательском интерфейсе. Настройки ECB, созданные с помощью платформы компонентов, ограничены. Вы можете определить только элементы ECB, которые не ссылаются на внешние файлы JavaScript или не используют встроенные вызовы JavaScript. Если вы действительно хотите расширить "современный" пользовательский интерфейс, необходимо выполнить обновление до SharePoint Framework.
Упрощенный доступ к информации в SharePoint и Microsoft 365
Еще один фундаментальный момент, который следует учитывать, заключается в том, что в устаревшей модели пользовательских пользовательских действий и настроек ЕЦБ было непросто использовать содержимое и данные SharePoint. Для этого нужно было использовать JSOM (клиентскую объектную модель SharePoint на JavaScript) или низкоуровневые REST API. Кроме того, было почти невозможно использовать полный набор служб Microsoft 365, если вы не использовали ADAL.JS (библиотека проверки подлинности Azure Active Directory для JavaScript) и пользовательский код JavaScript.
Теперь с помощью SharePoint Framework и расширений SharePoint Framework легко использовать REST API SharePoint и Microsoft Graph. Теперь вы можете создавать более мощные решения, которые могут использовать всю экосистему служб, предоставляемых Microsoft 365, и взаимодействовать с ними.
Сходства решений SharePoint Framework и настроек SharePoint Feature Framework
Пользовательские действия SharePoint Feature Framework и элементы ECB, а также настройки SharePoint Feature Framework имеют некоторые сходства.
Модель подготовки
Как расширения SharePoint Framework, так и пользовательские действия или решения элементов меню ECB используют XML-файл манифеста, который написан с помощью синтаксиса SharePoint Feature Framework. Развертывание основано на одних и том же методах.
Выполнение в составе страницы
Точно так же, как дополнительные действия пользователя и элементы ECB SharePoint Feature Framework, расширения SharePoint Framework являются частью страницы. Благодаря этому у таких решений есть доступ к модели DOM страницы и возможность взаимодействовать с другими компонентами на этой странице. Кроме того, это помогает разработчикам создавать решения, которые адаптируются к различным форм-факторам, в которых может отображаться страница SharePoint, включая мобильное приложение SharePoint.
Так как расширения SharePoint Framework выполняются в составе страницы, другим элементам на странице доступны те же ресурсы, что и настройке. Это важно учитывать при создании решений, использующих неявный поток OAuth с маркерами доступа носителя либо файлы cookie или хранилище браузера для хранения конфиденциальной информации. Так как расширения SharePoint Framework выполняются в составе страницы, другим элементам этой страницы также доступны все эти ресурсы.
Использование любой библиотеки для создания расширений
При создании настроек страницы с помощью пользовательских действий вы могли использовать библиотеки, такие как jQuery или Knockout, чтобы реализовать динамические настройки и лучше реагировать на взаимодействие с пользователем. Создавая расширения SharePoint Framework, вы можете совершенствовать свои решения, используя любую клиентскую библиотеку, как и раньше.
Дополнительным преимуществом, которое предлагает SharePoint Framework, является изоляция скрипта. Несмотря на то, что веб-часть выполняется как часть страницы, ее скрипт упаковается как модуль, позволяющий различным расширениям на одной странице использовать другую версию jQuery без столкновения друг с другом. Благодаря этой полезной функции вы можете сосредоточиться на коммерческой ценности решения, а не на технических особенностях миграции и компромиссах, связанных с функциональностью.
Запуск от имени текущего пользователя
В настройках на основе дополнительных действий пользователя и элементов меню ECB для связи с SharePoint достаточно было вызвать API. Клиентское решение работало в браузере в контексте текущего пользователя, а благодаря автоматической отправке с запросом файла cookie для аутентификации решение могло подключаться к SharePoint напрямую. Для связи с SharePoint не требовалась дополнительная аутентификация, как, например, при использовании надстроек SharePoint.
Такой же механизм применяется к настройкам на платформе SharePoint Framework, которые также работают в контексте текущего пользователя, поэтому для связи с SharePoint им не требуется дополнительная аутентификация. Контекст безопасности — это контекст подключенного в данный момент пользователя, что означает, что с точки зрения безопасности необходимо соблюдать осторожность при установке любого расширения SharePoint Framework в любом целевом семействе веб-сайтов.
Использование клиентского кода
Как расширения SharePoint Framework, так и дополнительные действия пользователя и меню ECB выполняются в браузере и могут содержать только клиентский код JavaScript. У клиентских решений есть ряд ограничений. Например, они не могут повышать разрешения в SharePoint и подключаться ко внешним API, не поддерживающим связь между источниками (CORS) и аутентификацию с помощью неявного потока OAuth. В таких случаях клиентское решение может использовать удаленный API на стороне сервера для выполнения необходимой операции и возврата результатов клиенту.
Модель размещения на основе Microsoft 365
Как расширения SharePoint Framework, так и пользовательские действия или элементы меню ECB могут размещаться в SharePoint Online, а затем в службе CDN Microsoft 365, что позволяет избежать необходимости в внешних службах или средах размещения.
Хотя размещение SharePoint Framework решений в сети CDN дает множество преимуществ, это необязательно, и вы можете разместить код в библиотеке документов SharePoint. SharePoint Framework пакеты (файлы *.sppkg), развернутые в каталоге приложений, указывают URL-адрес, по которому SharePoint Framework может найти код решения. Этот URL-адрес может быть каким угодно при условии, что пользователь, просматривающий страницу с расширением, может скачать скрипт из указанного расположения.
Microsoft 365 предоставляет общедоступную возможность CDN, которая позволяет публиковать файлы из определенной библиотеки документов SharePoint в CDN. Общедоступная сеть CDN Microsoft 365 обеспечивает хороший баланс между преимуществами использования CDN и простотой размещения файлов кода в библиотеке документов SharePoint. Если ваша организация не возражает против того, чтобы файлы кода были общедоступными, стоит рассмотреть возможность использования общедоступной сети CDN Microsoft 365.
Различия решений SharePoint Framework и настроек SharePoint Feature Framework
Однако между двумя моделями разработки также существуют различия, которые необходимо учитывать при создании архитектуры решений.
Работа на сайтах без скриптов
Так как SharePoint Framework решения, включая расширения, развертываются с помощью каталога приложений с предварительным утверждением, они не распространяются на ограничения без скриптов и работают на всех "современных" сайтах.
Стандартный набор точек расширяемости
В то время как пользовательское действие может внедрять код JavaScript, который может обновлять или изменять DOM любой части страницы, расширение SharePoint Framework может настраивать только поддерживаемые области "современных" страниц.
Теоретически вы можете создать настройщик заполнителей, который с помощью модели DOM полностью изменит структуру страницы, как было в случае дополнительных действий пользователя. В SharePoint Framework доступен более структурированный и надежный подход к настройке SharePoint. SharePoint Framework содержит специальные обработчики и заполнители для настройки SharePoint. Используйте их, а не элементы DOM.
Использование TypeScript для создания надежных и простых в обслуживании решений
При создании настроек с помощью пользовательских действий или элементов меню ECB разработчики часто использовали JavaScript. Зачастую в таких решениях не были предусмотрены автоматические проверки, что могло приводить к ошибкам при рефакторинге.
На платформе SharePoint Framework разработчики могут использовать систему типов TypeScript при создании решений. Благодаря системе типов многие ошибки перехватываются во время разработки, а не во время выполнения. Кроме того, рефакторинг стал проще, так как TypeScript защищает изменения кода. Так как JavaScript полностью совместим с TypeScript, переход не вызовет особых затруднений. Вы можете перенести обычный код JavaScript в TypeScript, постепенно расширяя возможности поддержки решений.
Отсутствие доступа к объектной модели JavaScript SharePoint по умолчанию
Создавая клиентские настройки для классического пользовательского интерфейса SharePoint, многие разработчики использовали для взаимодействия с SharePoint объектную модель JavaScript (JSOM). Модель JSOM обеспечивала автодополнение IntelliSense и удобный доступ к API SharePoint подобно клиентской объектной модели (CSOM). На классических страницах SharePoint основной компонент модели JSOM по умолчанию присутствовал на странице, а разработчики могли загружать дополнительные компоненты, например для взаимодействия со службой поиска SharePoint.
Современный пользовательский интерфейс SharePoint по умолчанию не включает модель SharePoint JSOM. Хотя разработчики могут загружать ее самостоятельно, рекомендуем использовать REST API или основную библиотеку JavaScript SharePoint PnP (JS PnP), которая использует REST API SharePoint на внутреннем уровне. Модель REST более универсальна и поддерживается в различных клиентских библиотеках, таких как jQuery, Angular и React.
Корпорация Майкрософт больше не занимается разработкой модели JSOM. Если вы предпочитаете работать с API, вместо этого можно использовать библиотеку JS PnP, которая предлагает простой API и typeScript.
Перенос существующих настроек в расширения SharePoint Framework
Перенос существующих настроек в расширения SharePoint Framework дает ряд преимуществ как пользователям, так и разработчикам. При рассмотрении вопроса о переносе существующих настроек в SharePoint Framework можно либо повторно использовать как можно больше существующих скриптов JavaScript, либо полностью переписать настройку с помощью TypeScript.
Повторное использование существующих сценариев
При переносе существующих настроек в расширения SharePoint Framework можно использовать существующие скрипты. Несмотря на то что платформа SharePoint Framework ориентирована на TypeScript, вы можете использовать обычный код JavaScript и постепенно преобразовывать его в TypeScript. Для краткосрочной поддержки решения или в условиях ограниченного бюджета этого может быть достаточно.
В решении SharePoint Framework не всегда можно повторно использовать существующие скрипты. Например, учитывая разнообразие библиотек JavaScript, определить, можно ли повторно использовать существующие скрипты в решении SharePoint Framework или нужно ли их переписать. Единственный способ узнать это — пробовать перемещать разные компоненты в решение SharePoint Framework и проверять их работу.
Повторное создание настройки
Если вам нужно поддерживать решение в течение более длительного периода времени или вы хотите лучше использовать SharePoint Framework или если окажется, что существующие скрипты не могут использоваться повторно с SharePoint Framework, вам может потребоваться полностью переписать настройку. Хотя это дороже, чем повторное использование существующих скриптов, он предлагает лучшие результаты в течение более длительного периода: решение, которое лучше работает и проще в обслуживании.
При перезаписи существующей настройки в SharePoint Framework решение следует начать с необходимой функциональности. Для реализации пользовательского интерфейса советуем использовать Office UI Fabric, чтобы решение выглядело как неотъемлемая часть SharePoint.