Перенос настроек JSLink в настройщики полей SharePoint Framework
Рекомендуемая SharePoint Framework (SPFx) — это рекомендуемая модель для расширения и создания настроек SharePoint. Если вы настроили поля SharePoint и представления списков с помощью JSLink, вам может быть интересно, в чем преимущество переноса этих настроек в SPFx.
Сначала рассмотрим доступные разработчикам варианты для создания расширений SharePoint Framework.
- Настройщик приложений. Расширьте встроенный "современный" пользовательский интерфейс SharePoint, добавив пользовательские элементы HTML и клиентский код в заранее определенные заполнители на "современных" страницах. Дополнительные сведения о настройщиках приложений см. в разделе Создание первого расширения SharePoint Framework (Hello World, часть 1)
- Набор команд. добавляет пользовательские пункты меню ECB и настраиваемые кнопки на панель команд или в представление списка или библиотеки. С этими командами можно связать любое действие на стороне клиента. Дополнительные сведения о наборах команд см. в разделе Создание первого расширения набора команд ListView.
- Настройщик полей. Настройте отображение поля в представлении списка, используя настраиваемые элементы HTML и клиентский код. Дополнительные сведения о настройщиках полей см. в разделе Создание первого расширения настройщика полей.
Выбор варианта зависит от цели настройки. Например, настройщики полей могут заменить собой настройки полей JSLink.
Совет
Хотя настройщики полей являются естественным путем миграции из JSLink, следует также оценить использование форматирования списка и столбца для настройки представления списка. Обе технологии имеют свои индивидуальные преимущества и недостатки, и одна из них может быть проще в реализации и обслуживании, чем другая в зависимости от вашего сценария.
Дополнительные сведения см. в статье "Использование форматирования столбцов для настройки SharePoint".
Преимущества переноса существующих настроек JSLink на SharePoint Framework
Этот SharePoint Framework был создан для расширения "современного" интерфейса SharePoint. "Современный" интерфейс доступен на "современных" сайтах групп и "современных" информационных сайтах, предназначенных для любого устройства и любой платформы.
Единственный поддерживаемый способ настройки "современных" списков и библиотек
Одним из основных преимуществ переноса устаревших настроек JSLink на SharePoint Framework является то, что это единственный поддерживаемый вариант. На самом деле "современные" списки и библиотеки из-за инфраструктуры отрисовки и флага без скрипта, включенного на "современных" сайтах, не могут полагаться на устаревшие настройки JSLink. Если вы действительно хотите расширить "современный" пользовательский интерфейс, необходимо перенести решение JSLink в настраиватель SharePoint Framework полей.
Упрощение доступа к информации в SharePoint и Microsoft 365
Еще один фундаментальный раздел, который следует учитывать, — в устаревших настройках JSLink было непросто использовать содержимое и данные SharePoint. Единственный способ сделать это — использовать клиентскую объектную модель JavaScript (JSOM) или низкоуровневые 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
Как настройки JSLink, так и настройки 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, не конфликтуя друг с другом. Благодаря этой полезной функции вы можете сосредоточиться на коммерческой ценности решения, а не на технических особенностях миграции и компромиссах, связанных с функциональностью.
Запуск от имени текущего пользователя
В настройках, созданных с помощью JSLink, для связи с SharePoint достаточно было вызвать соответствующий API. Клиентское решение работало в браузере в контексте текущего пользователя, а благодаря автоматической отправке с запросом файла cookie для аутентификации решение могло подключаться к SharePoint напрямую. Для связи с SharePoint не требовалась дополнительная аутентификация, как, например, при использовании надстроек SharePoint.
Такой же механизм применяется к настройкам на платформе SharePoint Framework, которые также работают в контексте текущего пользователя, поэтому для связи с SharePoint им не требуется дополнительная аутентификация. Контекст безопасности — это контекст текущего подключенного пользователя, что означает, что с точки зрения безопасности необходимо соблюдать осторожность при установке любого расширения SharePoint Framework в любом целевом семействе веб-сайтов.
Использование клиентского кода
Расширения SharePoint Framework и настройки JSLink выполняются в браузере и могут содержать только код JavaScript на стороне клиента. У клиентских решений есть ряд ограничений. Например, они не могут повышать разрешения в SharePoint и подключаться ко внешним API, не поддерживающим связь между источниками (CORS) и аутентификацию с помощью неявного потока OAuth. В таких случаях клиентское решение может использовать API на стороне удаленного сервера для выполнения необходимой операции и возврата результатов клиенту.
Модель размещения на основе Microsoft 365
Расширения SharePoint Framework и файлы JavaScript для настроек JSLink можно разместить в 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 и настройками JSLink
Однако между двумя моделями разработки также существуют различия, которые необходимо учитывать при создании архитектуры решений.
Работа на сайтах без скриптов и в "современных" списках и библиотеках
Так SharePoint Framework решения, включая расширения, развертываются через каталог приложений с предварительным утверждением, на них не распространяются ограничения без скриптов и они работают на всех "современных" сайтах. Как мы уже видели, настройщики полей SharePoint Framework в "современных" списках и библиотеках, а устаревшие JSLink — нет.
Настройщики полей позволяют настроить только представление
Настройка JSLink позволяет настроить не только представление поля в списке или библиотеке, но и отображение, а также представления редактирования поля для отдельного элемента.
На момент написания этой статьи настройщик полей SharePoint Framework может настраивать отрисовку поля только в режиме отрисовки представления списка, в то время как в представлениях отображения и редактирования одного элемента вы не можете использовать настройку.
Использование TypeScript для создания надежных и простых в обслуживании решений
Создавая настройки с помощью JSLink, разработчики часто использовали обычный код JavaScript. Зачастую в таких решениях не были предусмотрены автоматические проверки, что могло приводить к ошибкам при рефакторинге.
На платформе SharePoint Framework разработчики могут использовать систему типов TypeScript при создании решений. Благодаря системе типов вы можете находить ошибки во время разработки, а не во время выполнения. Кроме того, рефакторинг стал проще, так как TypeScript защищает изменения кода. Так как JavaScript полностью совместим с TypeScript, переход не вызовет особых затруднений. Вы можете перенести обычный код JavaScript в TypeScript, постепенно расширяя возможности поддержки решений.
Отсутствие доступа к объектной модели JavaScript SharePoint по умолчанию
При создании клиентских настроек для классического пользовательского интерфейса SharePoint многие разработчики использовали JSOM для взаимодействия с SharePoint. JSOM предлагает им IntelliSense и простой доступ к API SharePoint так же, как Client-Side объектной модели (CSOM). На классических страницах SharePoint основная часть JSOM по умолчанию присутствует на странице, и разработчики могут загружать дополнительные элементы для взаимодействия с поиском SharePoint, например.
Современный пользовательский интерфейс SharePoint по умолчанию не включает модель SharePoint JSOM. Хотя разработчики могут загрузить его самостоятельно, вместо этого рекомендуется использовать REST API или базовую библиотеку JavaScript (PnPJS) sharePoint Patterns and Practices, которая внутренне использует 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.