The last, and probably one of the most often used tools in your SharePoint Framework toolchain, is the SharePoint Workbench. This HTML page is served from a local filesystem by Node.js and loaded in a browser instance when you run gulp serve.
By default, SharePoint Workbench is dynamically loaded as workbench.html locally and is only accessible from your localhost. In addition, SharePoint Workbench also exists in SharePoint and can be used against a real Office 365 tenant or SharePoint 2016 to see how your code truly works.
In a typical development workflow with the SharePoint Framework, you'll mostly use the locally hosted workbench.html to test and see how your code works. When you're ready to package and test your code against SharePoint, you'll be using the hosted version from SharePoint 2016 or Office 365.
It's worth pointing out that the local version of SharePoint Workbench (workbench.html) does not require SharePoint installed locally. In fact, it only requires the packages from npm, that Yeoman generator kindly fetches for you, and nothing else! A network connection is not needed once npm install has been done.
In the following screenshot, you can see the status logs when SharePoint Workbench is being loaded locally:
When SharePoint Workbench has loaded, your default browser (in this case, Google Chrome for our sample) will try to load it from the localhost.
Upon loading SharePoint Workbench, you'll get a simple UI that mimics SharePoint. Microsoft even went to the trouble to add Office 365 in the top-left corner to make you feel as if you're truly debugging your code in the cloud. The reason SharePoint Workbench is highly efficient when used locally is that everything is running locally, thus there is no network latency. You can test, debug, and trial your code in mere seconds, and you don't have to wait for your code to first package, upload, and deploy to SharePoint. This latter approach would often take you anywhere from a minute to 5 minutes, and just to test small changes would mean that precious development time would be spent waiting for pages to load and for Office 365 to process your data first.
SharePoint Workbench provides a sample canvas (the large white area with the + -sign) where you can now add your sample code. In this example, an HelloWorld (client-side) web part was created and it's currently being debugged.
We can see that SharePoint Workbench is clever enough to automatically load our code from local disk, and by selecting the web part, we can drop it on the canvas.
We can also edit web part settings by clicking the pen icon.
The sample project only has one editable text field. The contents of this text field will be automatically rendered on the web part itself. When editing the text field, it is simultaneously updated on the actual web part on the left.
Obviously, we cannot save our changes if we choose to change the configuration settings for the web part, as there is nowhere to persist the changes. We can even try adding the very same web part multiple times on the page and this is a good practice to test when writing your code. Quite often, developers need to add external frameworks on the page, and by adding the web part multiple times, we can test that the frameworks are not loaded over and over again and that they do not cause havoc by being loaded more than once.
As responsiveness is built-in, and almost always preferred in the SharePoint Framework components, there is a simple but useful tool for testing your customizations against common devices. By clicking either mobile or tablet in the toolbar, we can easily check how content flows with different dimensions and capabilities.
Testing against an iPhone 5, we get a mock-up of the canvas and our web part. We can also change orientation from horizontal to vertical, and change between multiple devices.
In your development workflow, you typically run SharePoint Workbench when you need to test that your elements load correctly, or to debug client-side issues with browser developer tools.
The hosted version of SharePoint Workbench is always accessible under the /_layouts/workbench.aspx page. So a working address could be https://<tenant-name>.sharepoint.com/_layouts/workbench.aspx. If you access this page directly (without Node.js servicing your code), SharePoint Workbench will initially complain that it's not able to find any SharePoint Framework-based web parts running on your local machine.
There's some clever trickery involved here, as SharePoint Workbench is trying to figure out if you have a local SharePoint Framework web part running, and it's helping you as a developer by hosting that within the page in SharePoint.
When you have such a component being served locally (similarly to how you serve it with Gulp for a locally hosted SharePoint Workbench), the cloud-hosted version acts almost identically except within the context of the SharePoint site.
Note that when you're testing your code against the hosted version of SharePoint Workbench, you can also test how your web parts act together with other SharePoint web parts such as site news, image galleries, and other rich web parts.