Category Archives: Community

Fabric Snippets for VSCode Updated

Office Fabric UI Snippets for VS Code

Release Date: Dec 9, 2016

Version: 1.2.0*

Provided By: Sector 43 Software (David Mann)

Based on: Fabric JS release 1.2 (Nov 4, 2016)

Status: Stable


(* : Release numbers are now synchronized with the version of Fabric upon which they are based)

These snippets are intended to make the components from the Office UI Fabric project easier to use. In general, the HTML and Javascript is taken directly from the Office UI Fabric GitHub repository, with some tweaking.

All of the core snippets have a trigger that starts with uif so you can see what’s available by simply typing uif and looking at the Intellisense popup shown by VS Code. These snippets were originally developed for my Pluralsight course.

In some cases, the snippets are a combination of shortcut and learning tool. For example, some snippets contain both the markup and the JS code required by the component. Consider these a starting point – you will need to tweak the code to suit your needs, but the snippet at least gets everything you need onto the page.

Installation Instructions

  • Open the file VSCodeFabricSnippets.txt from the GitHub repo (direct link: https://raw.githubusercontent.com/Sector43/FabricSnippets/master/VSCodeFabricSnippets.txt
  • Select all of the contents and copy it to the clipboard
  • In VS Code, click File | Preferences | User Snippets and select HTML from the Language dropdown
  • Paste the contents from the GitHub file into the html.json file that is now open in VS Code
  • Save the html.json file and close it

The snippets are now available when you are editing an HTML file in VS Code.

Installation and usage is shown in the short video here: https://youtu.be/VsfUTwgNdgg Note that while this video is for the previous release of the snippets, installation and usage are essentially the same.

Known Issues

  • None

Generating Visual Studio Snippets

Paul Schaeflein contributed a small console application that will generate a Visual Studio .snippet file for each snippet in the VSCode snippet file. It doesn’t handle replaceable parameters (which are actually removed from the 1.2.0 release of the VSCode snippets anyway) but it gets most of the drudgery work done. The code is available in the SnippetConverter folder of the repo.

Reporting Bugs

Please report issues here: https://github.com/Sector43/FabricSnippets/issues

Office UI Fabric Snippets 1.0 Release

Update for Release 1.2: http://blog.mannsoftware.com/?p=2491

Office Fabric UI Snippets for VS Code

Release Date: March 25, 2016

Status: 1.0

Provided By: Sector 43 Software (David Mann)

Project: https://github.com/Sector43/FabricSnippets

Based on: Fabric release 2.01 (Feb 5, 2016)


These snippets are intended to make the Office UI Fabric easier to use. In general, the HTML is taken directly from the Office UI Fabric GitHub repository, with some tweaking.

Snippets generally fall into one of two flavors:

  • Simple Components: these have no JavaScript elements and so the snippet just expands into the correct HTML to render the component
  • Complex Components: these aren’t really “complex” they simply have some JavaScript associated with them. In these cases, there is a snippet for the component and one for an example of the JavaScript required to make the component work.

All of the core snippets have a trigger that starts with uif- so you can see what’s available by simply typing uif- and looking at the Intellisense popup shown by VS Code. These snippets were originally developed for my Pluralsight course so there are a handful of snippets that I built for the demos in that course. I’ve left them in just in case they provide value, or if you’re following along with the course. Here’s the info on them:

  • htmlShell – Creates the shell of an HTML page with the proper doctype for Fabric
  • jsAddPeoplePickerResult – sample code for adding a result into the Peoplepicker
  • gridRefRow – adds a single grid row with each cell set to 1 column wide. Useful for building a grid below and having a reference to see how many columns each cell takes up
  • gridDemoStyle – some style overrides used to differentiate the sample grid in the course
  • gridDemoRows – inserts the sample markup for a three column grid used as a demo in the course
  • callOutPositioning – sample styles for positioning a callOut
  • callOutPositioningJS – sample code for showing the callout in the demo
  • spinnerDemo – sample markup for working with the Spinner component
  • commandBarDemo – sample code for adding a ContextualMenu to a CommandBar
  • progressDemo – sample code and markup for the Progress Indicator demo

Installation Instructions

For the time being, installation is manual. Once I’ve ironed out any bugs, I’ll make a true VS Code extension and deploy it to the Extension Gallery. At that point, I’ll also create a Visual Studio Extension and deploy that to the Visual Studio Gallery as well. If there is interest, I’ll convert the snippets to other editors – Sublime is one I’m considering, but am open to other suggestions as well.

To Install:

  • Open the file VSCodeFabricSnippets.txt from the GitHub repo (direct link:https://raw.githubusercontent.com/Sector43/FabricSnippets/master/VSCodeFabricSnippets.txt
  • Select all of the contents and copy it to the clipboard
  • In VS Code, click File | Preferences | User Snippets and select HTML from the Language dropdown
  • Paste the contents from the GitHub file into the html.json file that is now open in VS Code
  • Save the html.json file and close it

The snippets are now available when you are editing an HTML file in VS Code. (NOTE: Snippets in VS Code only seem to work if the HTML file is open as part of a folder, not if you just open a standalone file. I’m looking into whether this is really true, and if so whether it is by design or a bug)

Installation and usage is shown in the short video here: https://youtu.be/VsfUTwgNdgg

Known Issues

  • None

Next Steps

  • Updating for latest Fabric release (currently 2.2.0)
  • Creating Visual Studio snippets

Please report other issues here: https://github.com/Sector43/FabricSnippets/issues

Developing with Office UI Fabric Course is Live

The second and final course in my series on the Office UI Fabric is now live: http://s43.io/FabricCourse2.  Following on from the introduction in the first course, this course dives in to hands-on working with Fabric as a developer.  It is very light on slides and heavy on demos.

Here’s a look at the Table of Contents:

  1. Getting Started with Office UI Fabric (including an introduction to the Fabric Snippets)
  2. Handling Multiple Resolutions with the Responsive Grid
  3. Building Forms
  4. Improving User Interactions with Display Components
  5. Enhancing Layout and Navigation
  6. Building Fabric and Contributing to the Project
  7. Using Fabric in Angular
  8. Resources and Fabric Futures

Obviously, I’m a little biased, but I think the course covers everything you need to know as a developer to use Fabric in your own applications, sites and add-ins.  I cover every component in Fabric, showing the HTML and JavaScript necessary to make it work as well as a deep dive on all aspects of the responsive grid and then cover the Fabric project itself on GitHub and the community project ngOfficeUIFabric for using Fabric in Angular.

Enjoy!

Fabric Explorer Updated

To coincide with the publication of my new Pluralsight course on Office UI Fabric, I’ve updated the Fabric Explorer Chrome extension I published a while back to version 1.3.  This is a minor update, but it fixes a few bugs:

  1. Added support for pages loaded into the browser via a file:// URL
  2. Fixed bugs that prevented the “Reset” button from correctly returning an element back to it’s original state when the page was loaded

In addition, I added the remainder of the Fabric Responsive Grid classes (hidden, offset, push, pull), did some minor code cleanup and published the source code to GitHub.

The update was published on the Chrome Web Store this morning and should be automatically updated if you already have it installed.  If you haven’t installed it already, now is the perfect time to do so!  You’ll get the latest and greatest bits right away.

Please log any bugs here: https://github.com/Sector43/FabricExplorer/issues

The extension is available here: https://chrome.google.com/webstore/detail/fabric-explorer/iealmcjmkenoicmjpcebflbpcendnjnm 

Office Fabric UI Snippets for VS Code

Update for Release 1.2: http://blog.mannsoftware.com/?p=2491

Update for Release 1.0: http://blog.mannsoftware.com/?p=2371

Release Date: Feb 26, 2016

Status: Beta

Provided By: Sector 43 Software (David Mann)

Details: s43.io/FabricSnippets

Repo: https://github.com/Sector43/FabricSnippets

Based on: Fabric release 2.01 (Feb 5, 2016)


These snippets are a first go at making the Office UI Fabric easier to use. In general, the HTML is taken directly from the Office UI Fabric GitHub repository, with some tweaking.

Snippets generally fall into one of two flavors:

  • Simple Components: these have no JavaScript elements and so the snippet just expands into the correct HTML to render the component
  • Complex Components: these aren’t really “complex” they simply have some JavaScript associated with them. In these cases, there is a snippet for the component and one for an example of the JavaScript required to make the component work.

All of the snippets have a trigger that starts with uif- so you can see what’s available by simply typing uif- and looking at the Intellisense popup shown by VS Code.

Installation Instructions

For the time being, installation is manual. Once I’ve ironed out any bugs, I’ll make a true VS Code extension and deploy it to the Extension Gallery. At that point, I’ll also create a Visual Studio Extension and deploy that to the Visual Studio Gallery as well. If there is interest, I’ll convert the snippets to other editors – Sublime is one I’m considering, but am open to other suggestions as well.

To Install:

  • Open the file VSCodeFabricSnippets.txt from the GitHub repo (direct link: https://raw.githubusercontent.com/Sector43/FabricSnippets/master/VSCodeFabricSnippets.txt)
  • Select all of the contents and copy it to the clipboard
  • In VS Code, click File | Preferences | User Snippets and select HTML from the Language dropdown
  • Paste the contents from the GitHub file into the html.json file that is now open in VS Code
  • Save the html.json file and close it

The snippets are now available when you are editing an HTML file in VS Code. (NOTE: Snippets in VS Code only seem to work if the HTML file is open as part of a folder, not if you just open a standalone file. I’m looking into whether this is really true, and if so whether it is by design or a bug)

Installation and usage is shown in the short video here: https://youtu.be/VsfUTwgNdgg

Known Issues

The following components are not currently supported by the snippets:

  • Facepile
  • People Picker
  • Persona
  • Persona Card

They’ll be coming in the next release.

Please report other issues here: https://github.com/Sector43/FabricSnippets/issues

All Developers Can Be SharePoint Developers

That’s the title for a full-day session I’m doing at the upcoming Philly Code Camp (October 10, 2015, Philly MTC in Malvern – more information).  Registration is only $76 and includes breakfast and lunch, raffles, guaranteed admission to the Saturday regular Code Camp (which will sell out), and more.  Register here.

Here’s the synopsis for the day:

Until recently, SharePoint was the red-headed stepchild of the Microsoft web development world, requiring intimate knowledge of SharePoint and it’s gargantuan object model. This made SharePoint a very specialized skill-set that stood off to the side on its own. It’s lack of support for standard web-development practices made it difficult for new developers to learn – or to even want to learn.

Fortunately, this has changed.

SharePoint 2013 has joined the rest of the web-development world – supporting standard technologies such as REST, and languages ranging from .NET to Perl, PHP, Ruby, etc. JavaScript is now a first-class citizen. Gone are the days when “doing SharePoint” required extensive, arcane knowledge. For developers, SharePoint is now just another data store accessible via a robust, REST-based API.

In this full-day session, SharePoint MVP David Mann will introduce the SharePoint REST API and show how it can be used to build client-side applications using JavaScript, utilizing popular frameworks such as Angular and libraries such as JQuery, common tools like Node, Bower, Gulp and Yeoman, as well as rich-client applications using C#. This includes both on-premises installations of SharePoint as well as cloud-based environments such as Office 365.

Bring your laptops as this is a hands-on session. No SharePoint experience is necessary, but basic programming skills would be a big help. This is a great opportunity to add SharePoint to your toolkit, or to take your SharePoint skills to the next level. Individuals and teams are welcome.


I’m still tweaking the material, but here is the current agenda:

  1. Introduction & Getting Started (including why SharePoint? )
  2. Setting up the Environment
  3. Setting up the Environment (Lab)
  4. Tools & Frameworks
  5. Tools & Frameworks (Lab)
  6. The SharePoint REST API
  7. Hello (SharePoint REST) World (Lab)
  8. CRUD Operations
  9. CRUD Operations (Lab)
  10. Provisioning
  11. Provisioning (Lab)
  12. Language Agnostic – C#, Ruby, [Insert favorite language here]
  13. Language Agnostic (Lab)
  14. Wrap Up and Next Steps

I’ll post more details as we get closer.

To follow along with the labs, you’ll need:

  • a laptop with Visual Studio (2013 or 2015)  installed

That’s it.  You will not need SharePoint installed

Office 365 Update

I’m presenting at my user group (TriState SharePoint) tonight for our periodic session covering the latest updates to Office 365.  All of the content for this is coming from my Office 365 Concierge newsletter, but with demos and more detailed discussions on some topics.  The slide deck from the session is available here: http://blog.mannsoftware.com/wp-content/uploads/2015/02/Office%20365%20Update%202-2015.pdf

Part 2: Loading JavaScript Libraries (It Still Shouldn’t Be This Hard)

My post on Sunday seems to have struck a little bit of a nerve.  A number of folks added comments to the blog post and a few others commented directly to me via email or other channels.  In this post, I’m going to quickly summarize and respond to some of the comments and then move on to step two – trying to formulate thoughts for moving forward, if there is in fact a path to move forward any further.

OK, here we go, in no particular order…

(Oh, yeah, perhaps this goes without saying, but these are largely opinions based on my experience and stories I hear from other developers.  YMMV, and I’d *love* to be proven wrong about some of these, but let’s make sure to keep the discussion productive and moving towards a solution).

  • Marc’s concept of “Functions as a Service” (FAAS) is interesting and one I think should be investigated and fleshed out.  I haven’t read the book chapter Marc references, so maybe he’s already done that…Marc?
  • Hugh’s mention of JSFiddle as a case study is *exactly* what I had in mind for a part of this.  For small-scale customizations implemented by an end user, selecting a library or two needs to be as dirt simple as JSFiddle.  I think this ties in to FAAS as well.
  • As a few folks mentioned, this is not entirely a technical problem.  Regular old Governance comes into play in a big way.  Too, if anything comes of this, we must get a groundswell of community support behind it as a “standard”.
  • This is perhaps a semantic argument, but contrary to what a few folks posted, I think there *is* a one-size-fits-all solution, or at least one-size-fits-most – there’s always going to be edge cases that don’t work.  The semantics comes in because I’ll call it one solution with a couple of facets, but all falling under one umbrella.
  • SPO (Office 365) and MDS must be addressed
  • Supporting MDS is somewhat difficult, and more than just not polluting the global namespace
  • RequireJS is a great example of managing dependencies and loading modules. I use it frequently, as do many developers. Unfortunately, as it stands right now, it is not MDS-compliant (it creates script nodes using CreateElement)
  • Loading multiple versions of the same library is a performance and memory use problem, but also breaks some libraries (like JQueryUI, and probably a bunch of other JQuery plugins, though I haven’t tested them).  Namespacing doesn’t fix all of this.
  • The other problem with loading multiple libraries is also compounded by a lack of control over load order.  SharePoint has too many ways to load libraries and they all load at different times.
  • A comment was made that “most companies would not want to advertise the existence of a “standard library loader” to general users… since that would implicitly suggest that ad-hoc customization is ok…maybe even supported” which part of me agrees with, but a bigger part of me thinks those companies are just burying their heads in the sand.  Unless they somehow hide the Script Editor webpart (which some do, I know) they have people doing customizations and ignoring it doesn’t make it go away.  They’d be better off embracing and providing some guidance/support.  This also plays into my “one solution with many facets” approach – companies can choose which pieces they wish to implement to cover their scenarios.
  • Another comment was “As a developer you should be working to make YOUR js libraries isolated from anyone else.”  I think this is wrong.  This is not being a good corporate citizen.  This is the “too hell with everyone else” scenario in my original post.  I agree that you should isolate your code as much as possible, but unless everyone is there can still be problems.  Too, your code is not the only code running in the environment.  The only exception to this I can think of is if you are developing an application as an ISV or internal developer/consultant and your application is entirely self-contained – you control the horizontal and the vertical.  However, if you develop even one web part as part of your application, you don’t have that level of control – users could add that webpart outside of your application.  If you integrate with OOB SharePoint – even just using its Master Page – you don’t have that level of control.  If your application allows Custom Actions to load, you don’t have this level of control…etc., etc., etc.  Even if your stuff is perfectly insulated and always works, it may break something else or cause some other problem.
  • A few folks commented along the lines of user’s maintaining/understanding/impacting their code.  This falls under the previous bullet.  In most cases, your code is not the only custom code running in the environment
  • A big part of the problem is that we cannot say that this is only of concern to professional developers.  While I personally dislike the term “citizen developer” I agree with the fact that non-developer users are customizing SharePoint and using JavaScript they cobble together from the internet or simple trial and error, and they too often “ship it” as soon as it appears to do what they want with no additional testing or documentation.  This ship has sailed and there’s no way we’re bringing it back to port, much as we might want to.  (And yes, I realize that some of those “citizen developers” do very good work – better than some developers – but I’m mostly concerned with those who don’t)
  • I have not specifically noticed the “jarring effect” some folks mentioned, but maybe I’m just missing it.  I’ll dig out some code I wrote that should show it and try to pay more attention.

I think that sums up my responses and follow-on comments.  Now to move forward…

As I see things in my twisted little mind, here’s what we need, from a technology point of view (governance is next, don’t worry).  This is very much of a blue sky wish list and I realize that some of it may not be feasible/possible.

  • A replacement for the Script Editor web part that simplifies things for end users to allow them to pick the libraries they need and guides them towards some minimal “best practices” – a very lightweight linter of some sort that enforces a few basic rules would be a good start.  Optionally blocking inline script tags would also be nice (so MDS doesn’t break).  I think 99.9% of the time, simply telling them that JQuery is already available will be sufficient, so this doesn’t have to be fancy.
  • A way to track which libraries and versions are available globally (scoped to a given web, I think)
  • A way for developers to specify/discover which libraries are loaded and the order in which they load
  • A fast, reliable way to load and initiate a script loader which can then load other required scripts
  • An MDS-compliant way to specify dependencies between modules and load order

I’ve probably missed a few things, but that’s a start.

For governance, here’s my wish list:

  • Documentation of whatever the technology solutions are
  • Consensus amongst developers that whatever “this” is, it is the recommend way to proceed (although I acknowledge this is like herding cats and will never be close to 100%)
  • Training/education material for end users and developers

So where do we go from here?  Next is a viability assessment of the technology wish list.  What’s possible?  What’s feasible?  After that, if enough of the technology can be made to work then we kick off a community project.  Or we talk to Microsoft about carving off a little corner of the PnP world for this effort and get a little help from the mother ship (which would also go a long way in getting buy in from developers and companies).

This may all very well be a pipe dream, but I’m somewhat known for tilting at windmills (and metaphors, mixed or otherwise) but if we don’t at least try to come up with a solution to a problem, all we’re doing is complaining and that’s just wasted energy.

As always, comments welcome.

Dave