Best Practices for Small-Scale Client-Side Development in SharePoint Marc D Anderson President, Sympraxis Consulting LLC

SPS Boston 2016 is made possible by our Sponsors Mindsharp Contego Cyber Solutions

ShareP nt Visit extaCloud’s booth for Drink Tickets! Champions Bar 6pm LOCATED IN BOSTON MARRIOTT CAMBRIDGE 2 Cambridge Center Cambridge, MA 02142 (1 min walk from Microsoft) http://www.championscambridge.com/

Who Is Marc? Co-Founder and President of Sympraxis Consulting LLC, located in the Boston suburb of Newton, MA, USA. Sympraxis focuses on enabling collaboration throughout the enterprise using the SharePoint application platform. Over 30 years of experience in technology professional services and software development. Over a wide-ranging career in consulting as well as line manager positions, Marc has proven himself as a problem solver and leader who can solve difficult technology problems for organizations across a wide variety of industries and organization sizes. Author of SPServices Awarded Microsoft MVP for SharePoint Server 2011-2016

Overview ​We can build real solutions by using SharePoint and Office 365 as service endpoints that provide us with all sorts of critical business data. On the spectrum between power user dev and enterprise development, there’s plenty of room for departmental or even company-wide solutions that work entirely client side. Often the difference between “enterprise” development and the rest comes down to two factors: The governance or guidance around deployment The size of the development team In this in-depth session, we’ll look at some better practices for building solutions, storing and managing code, and source code control for smaller size projects that don’t have complex deployment requirements.

SharePoint Development Model Evolution “Nearly of large enterprises will likely have hybrid cloud deployments by the end of 2017”1 50% of customers are leveraging cloud for their applications—from pilots to production apps2 72% Server Side Development 2001 ASP Digital Dashboards, File System Storage, etc. 2003 ASP.NET ASP.NET Web Parts, Full Trust APIs, Server Side Event Receivers… 2007 ASP.NET ASP.NET Web Parts, Full Trust APIs, Server Side Event Receivers… 2010 ASP.NET ASP.NET Web Parts, Full Trust APIs, Server Side Event Receivers… 2013 ASP.NET ASP.NET Web Parts, Full Trust APIs, Server Side Event Receivers… Sources: Gartner, Inc. 2013. Press Release: http://www.gartner.com/newsroom/id/2599315 451 Research, Hosting and Cloud Study, 2014

Development models Across SharePoint Versions Server Side Client Side Sandboxed solutions App model Sandboxed solutions App model Sandboxed solutions App model Sandboxed solutions SharePoint Framework

Client Side Code Has Been in SharePoint Forever

This Is Not Your Grandfather's Client Side… …or your Grandmother's, for that matter

SharePoint Development Is [Becoming] Web Development Use your favorite tools Choose your favorite frameworks Write your solutions with HTML, CSS, and JavaScript Watch your users smile

Decouple Development and Deployment Decisions Decide what you need the functionality to be Choose your development tools to best achieve the functionality Consider how you might package Build Devise your deployment scheme Deploy

"Client Side" Is Not One Thing Simple Complex Content Editor Web Part Script Editor Web Part SharePoint Framework One-off, quick solutions with JavaScript / HTML embedded directly in the CEWP Code can still be centralized Centralized code artifacts with a light development pipeline Centralized code artifacts with a more robust development pipeline Reusable components (Client Side Web Parts) with a more formal development process Centralized admin and deployment Each approach still has value, even in the "modern" era

High Level Structure of Building SharePoint Solutions JavaScript HTML CSS Data Access / Initial Manipulation Templates Application Styling Has to coexist with SharePoint's CSS Be very specific with your selectors ViewModel / Application Logic Avoid hauling in SharePoint's baggage unless you need it ePoint's baggage "Document Ready"

Services Across SharePoint Versions SOAP REST Endpoint None /_vti_bin/listdata.svc Deprecated Deprecated /_api Deprecated https://graph.microsoft.com/v1.0

Where Should I Put My Stuff? Widgets in one Site Collection Widget in one tenant/farm, multiple site collections Widgets used across multiple tenants/farms* Store code in a library in a specific subsite  X Store code in a library in the root site of the Site Collection Store code in a Site Collection specifically for client side code O Create an actual CDN (Azure, AWS, dedicated server, other commercial CDN provider…)** - Good solution O – Optional solution, potentially overkill X – Not a great choice * - Not referencing any code that would be part of a commercial solution. ** - CDNs or Content Delivery Networks allow “content” to be made highly available to end users everywhere. If you store your code in a different Site Collection or CDN, you may need to bootstrap it into place. See: Code Creep - SharePoint "CDN" by Julie Turner (@jfj1997)

Bootstrapping JavaScript Microsoft guidance is to no longer edit the master page – and we don't have to Adding a User Custom Action allows you to load the first JavaScript file with a ScriptLink RequireJS (or several alternatives – see system.js) allow you to bootstrap the rest of your code into the page Because your script references can be built in code, you can even do versioning See: The easiest way to add Script and Brand your SharePoint and SharePoint Online by John Liu

Bootstrapping HTML HTML files are trickier to load because CEWPs can't use a Content Link outside the Site Collection jQuery $.get() Widget Wrangler RequireJS with text plugin See: jQuery $.get(), Office Dev PnP Web Cast – Introducing Widget Wrangler for SharePoint development, RequireJS text plugin

Choose a Framework Don't be caught up in the "shiny penny" syndrome Compare your known requirements with the frameworks' capabilities Ask yourself: What types of solutions do we need to build? What does our governance tell us about our deployment model? How big is the development team? What are our current skills?

The Popularity Contest See: The State Of JavaScript: Front-End Frameworks: A few preliminary results

Source Control and Code Management Code Editor spsave See: Sympraxis’ SharePoint Client Side Development Pipeline

Source Control and Code Management: gulpfile See: Sympraxis’ SharePoint Client Side Development Pipeline

What Do You Need to Know? SPFx uses common Web development tools and frameworks How deeply you go depends on your specific needs

SharePoint Framework Sessions Developing SharePoint Widgets in TypeScript with Bob German @ 2:30 Preparing for the next shift in SharePoint development with Jay Landrum @ 4pm

Demos

Contact Information Email marc.anderson@sympraxisconsulting.com Twitter @sympmarc Blog http://sympmarc.com SPServices http://spservices.codeplex.com SPXSLT http://spxslt.codeplex.com Books http://sympmarc.com/books The Middle Tier Manifesto http://bit.ly/middletier