Разработчики SharePoint все больше привыкают в современным подходам клиентской разработки. Сама front-end разработка для SharePoint превращается в некий гибрид использования Visual Studio Code, Gulp задач и инструментов разработки Chrome (Dev Tools + Workspaces).
Все больше подходов и инструментов из "хипстерской тусовки" оседают как профессиональные средства, без которых сам процесс кодинга кажется уже невозможным. Однако, всегда есть что-то, чего не хватает для полноты картины. Чтобы хотелось видеть после того, как в редакторе кода нажимется "Ctrl+S"? Правильно, чтобы изменение было сразу отображено на живой странице портала. Возможно кто-то скажет - "А как же BrowserSync (это модуль, позволяющий динамически отслеживать изменения в локальных исходниках и обновлять страницу отладки)?". "А Вы пробовали его подружить с SharePoint?", отвечу я.
В SharePoint есть ряд специфических нюансов, которые не позволят BrowserSync предоставить все, что хотелось бы. К счастью, теперь есть альтернатива.
Не так давно я обернул используемый нашей командой подход в библиотеку, оформленную в виде подключаемого NPM модуля - sp-live-reload.
С помощью sp-live-reload возможно сохранять локально редктируемые файлы front-end проекта, такие как javascript, css, html (источник для CEWP), apsx (например, layout без серверного кода), masterpage и сразу полсле сохранения видеть применившиеся измеенния в браузере без необходимости вручную перезагружать страницу:
Для подключения библиотеки в Node.js проект необходимо выполнить в консоли:
npm install sp-live-reload --save-devПосле чего, возможно будет создать и запустить Gulp задачу, как описано в документации к проекту.
Мы используем горячее обновление в комбинации с SPSave, модулем, позволяющем загружать/публиковать файлы проекта непосредственно в библиотеки "ассетов" SharePoint (например, /_catalogs/masterpage/namespace). Так же можно использовать sp-live-reload в связке с альтернативами принцип один и тот же.
var gulp = require('gulp');
var spsave = require("gulp-spsave");
var watch = require('gulp-watch');
var through = require('through2');
var LiveReload = require('sp-live-reload');
var config = require('./gulp.config');
gulp.task("watch-assets", function () {
console.log("Отслеживание изменений...");
console.log("Убедитесь в том, что на странице развернут скрипт мониторинга.");
var liveReload = new LiveReload(config);
liveReload.runServer();
return watch(config.watchAssets, function (event) {
console.log(event.path);
gulp.src(event.path, {
base: config.watchBase
}).pipe(spsave(config.spsaveCoreOptions, config.spsaveCreds))
.pipe(through.obj(function (chunk, enc, cb) {
var chunkPath = chunk.path;
liveReload.emitUpdatedPath(chunkPath);
cb(null, chunk);
}));
});
});Обозначу соображение, из которых мы исходим, предоставляя решение:
- Горячее обновление это для разработки и только для сред разработки, ни в коем случае не для Production-сред
- При работе нескольких разработчиков на одной среде (SPSite) потенципльно могут быть конфликты, которые нужно обходить в зависимости от схемы совместной работы
- Должны поддерживаться все основные браузеры
Наш подход в реализации горячего обновления следующий:
- Скрипт мониторинга изменений может быть развернут в SharePoint двумя способами:
- Ручной (или точечный) непосредственно на страницу, где производится отладка
- Глобальный (custom action в рамках SPSite) - на всех страницах узла
- Скрипт мониторинга обращается к локально запускаемому серверу на машине разработчика, который отправляет информацию об обновленных ресурсах сразу после их доставки в SharePoint
- Для глобального развертывания можно использовать Gulp задачи по развертыванию и удалению сustom action, глобальное развертывание целесообразно, если в SPSite работает продолжительное время единственный разработчик, но могут быть и исключения
- Когда с одинм SPSite работают 2 и более разработчика скрипт мониторинга провизится только в одном экземпляре, при этом на всех машинах разработки должны быть одинаковые настройки URL и порта сервера
- Для обновления скрипт мониторинга учитывает только ресурсы, присутствующие на открытой страницы, изменение ассетов, не задействованных на странице игнорируется
Пару слов об архитектуре реализации. Клиент и сервер мониторинга используют сокетные соединения предоставляемые Socket.io для транспорта сообщений в реальном времени. Все браузеры, поддерживающие Socket.io и SharePoint автоматически поддерживаются sp-live-reload. Сервер мониторинга изменений запускается в рамках задачи Gulp по отслеживанию ресурсов для публикации. Может быть не обязательно Gulp, но дня него есть поддержка "из коробки". При изменении, сразу после публикации измененного файла, сервер транслирует сообщение с путем до файла. Клиент мониторинга получает все сообщения от сервера и, в зависимости от наличия данных ресурсов на странице, производит перезагрузку страницы или самих ресурсов (как в случае с css - обновление происходит без необходимости перезагрузки). Клиент учитывает особенности SHarePoint, перезагрузку вызывают не только обновления скриптов, но и HTML, которые могут быть источником содержимого CEWP веб-частей, а так же ASPX с шаблонами отображения страниц публикации (layouts) или же используемая главная страница (masterpage).
Горячее обновление работает как с On-Premises установками SharePoint (2016 и 2013), так и SharePoint Online. В случае с SharePoint Online есть пара нюансов: во-первых, работа через HTTPS - необходимо запускать локальный сервер тоже на HTTPS, для этого немного нужно один раз повозиться с сертификатами, во-вторых, готовьтесь, что SharePoint Online медленный как черепаха! =)
sp-live-reload так же интегрирован в generator-sppp, Вы можете попробовать его в действии с минимальными усилиями, развернув стартовый проект из генератора.
