SPFX – Redesign webpartów w SharePoint

Najstarsza wersja SharePoint z jaką miałem okazję współpracować to SP 2010. Porównując developerskie doświadczenie z WebPartami dla SharePoint, można dojść do wniosku nie zmieniły się one za bardzo na przestrzeni lat. Czy rozwiązania sprzed lat wciąż są w stanie sprostać wymaganiom klientów oraz developerów? Czy dług technologiczny ciągnący się za tym rozwiązaniem nie staje się zbyt ciężki?

Wytarte Ścieżki

Standardowe WebParty dla SharePoint to faktycznie aplikacje napisane w ASP.NET, hostowane obok SharePoint – trudno jest, za pomocą tej techniki, uzyskać dynamiczne strony internetowe bez przeładowań. W dodatku programiści tworzący takie rozwiązania potrzebują skomplikowanego środowiska, którego czas konfiguracji jest dość długi. Co gorsza, najczęstszym modelem jest umieszczenie WebParta na stronach SharePoint poprzez iframe. Obecnie znacznik ten jest uznawany za przestarzały, niezbyt wygodny, a wręcz niebezpieczny.

Przykład

Jako przykład nieprzystosowania pozwolę sobie pokazać fragment WebParta w którym ostatnio dokonywałem zmian wizualnych. Dodatkowym wymogiem było wyświetlanie obrazków w formie lightboxa ( wyśrodkowane powiększone zdjęcie z wyciemnieniem tła). Próba kliknięcia w obrazek skutkowała smutnym widokiem:

lightboxfail

Jak widać zacieniowany obszar pokrywa się tylko z obszarem iframe’a. Zapewne możliwe jest rozwiązanie tego problemu przemyślanym kawałkiem JavaScriptu lub CSS’a – pytanie tylko, czy chcemy myśleć nad takimi rozwiązaniami za każdym razem gdy próbujemy osiągnąć coś niekoniecznie szablonowego?

Nie chcemy!

Narzędzia z jakich korzystamy powinny dopasować się do potrzeb, stąd przestarzała już nieco, koncepcja klasycznych WebPartów doczekała się konkurencji.

SPFX, lub jak kto woli SharePoint Framework to nowy sposób na tworzenie WebPartów ( obecnie dostępna tylko dla SharePoint Online).

Nowoczesne rozwiązania

Tworzenie WebPartów z pomocą SPFX opiera się w dużej mierze o node.js. Tworzenie projektu odbywa się poprzez konsolę i przyjazny instalator yeoman.io, który w dodatku w trakcie instalacji zapyta, czy na przykład nie chcemy korzystać z Reacta:

yeo.png

Samo rozwiązanie powstaje w oparciu o popularny język TypeScript, dzięki temu programista zachowuje swobodę programowania webowego, a jednocześnie ma możliwość używania twardego typowania i strukturyzacji logiki. Dzięki takiemu podejściu nawet programiści przyzwyczajeni do C# powinni szybko odnaleźć się SPFX.

W końcu czy poniższa struktura nie wygląda znajomo?

typescript

Kolejnym dużym plusem jest możliwość skorzystania z Node Package Manager. Programista nie musi pisać wszystkich elementów od zera – NPM za darmo oferuje 475 000 różnego rodzaju paczek, od rozwiązujących skomplikowane obliczenia, do gotowych wykresów, kalendarzy i innych elementów.

Wygodne środowisko pracy

Pracując z SPFX wykorzystujemy do testowania narzędzie gulp.

Wystarczy, że w konsoli developer wpisze:

gulp serve

Efektem będzie zasymulowane środowisko o budowie podobnej do SharePoint, na którym możemy testować rozwiązania. Od teraz programista pracuje bez każdorazowego wgrywania paczki na serwer. Wgramy paczkę i zmienimy wersję gdy wszystko już będzie gotowe.

workbench

Wygoda tworzenia

Aplikacje tworzone w SPFX są zagnieżdżone w inny sposób niż klasyczne WebParty – nie znajdują się w znaczniku iframe – są po prostu elementem DOM. Dzięki temu rozwiązaniu znajdują się w tym samym dokumencie co reszta witryny. To stwarza wiele możliwości.

Po pierwsze – za pomocą właściwości obiektów document oraz window możemy współdzielić dane pomiędzy wieloma webpartami – takie rozwiązanie pozwala na rozszerzenie standardowych elementów o wielokierunkową komunikację.

Na przykład możemy stworzyć webpart listy pracowników, oraz drugi, który jest widoczny tylko gdy wybierzemy osobę na liście a jego zadaniem jest wyświetlanie np. statystyk sprzedaży wskazanego pracownika. Należy też zaznaczyć, że taka komunikacja jest bardzo prosta, można ją skonfigurować za pomocą atrybutu okna lub dokumentu, a także za pomocą zdarzeń:

document["selectedUser"] = this.selectedUserId;

lub:

//Na liście użytkowników
var event = new CustomEvent('selectedUserChanged', { selectedUser: id });
event.initEvent('selectedUserChanged', true, true);
document.dispatchEvent(event);

//Na webparcie z wykresem
elem.addEventListener('selectedUserChanged', 
    function (e) { handleUserChange(e);
}, false);

 

Wyjść poza ramkę

Ponadto – możliwe jest również ingerowanie w wygląd samego SharePointa z poziomu WebParta. Na dokumencie i jego dzieciach możemy zwyczajnie wymuszać różnego rodzaju zmiany (koloru, rozmiaru etc.). To wszystko możemy wykonać na przykład za pomocą powszechnie znanej biblioteki jQuery – zupełnie jakbyśmy zrobili to na zwykłej stronie HTML a nie w SharePoint:

$('body').css('background-color', '#0A92FB');

Referencja do głównego trzonu dokumentu daje nam też możliwość dodawania własnych elementów, które na przykład będziemy chcieli przyczepić do konkretnego miejsca w oknie. Wystarczy, że do dokumentu dodamy odpowiedni element DOM.

Na początek CSS

.mrClipper{ 
  position:absolute; 
  bottom:50px; 
  right:50px; 
  z-index:999; 
  display:block; 
  width:100px; 
  height:100px; 
  background-image:'clipper.png';
}

A teraz wewnątrz webparta:

document.body.innerHTML += "<div class='mrClipper' ...

W ten sposób możemy wskrzesić Pana Spinacza w SharePoint Online 🙂

Podsumowanie

SPFX wciąż się rozwija, ale już teraz oferuje zmianę jakości pracy nad WebPartami. Warto być na bieżąco – ten framework może zrewolucjonizować tworzenie aplikacji dla SharePoint.

Baza wiedzy

Tutorial SPFX

Node Package Manager

Yeoman