Let's Make Workbench Even More Useful!

[lucabandMSFT]

Greeting Folks,
We know the workbench is currently used quite a bit by all of you and we would like to make it more useful as we know we have not evolved it in a while.

After an initial brainstorming, we came out with the following ideas to make the workbench a better tool. But, ultimately, this has to be a tool that all of you use; so we would really love to get your feedback and learn what would be useful for you.

Those are the ideas we thought about so far:

• showing "time to load" for web part lifecycle events (init, render, etc.)
• showing the amount of JavaScript that was downloaded overall from your component(s) and the time required to download it
• when the component calls an AAD API (e.g. MSGraph), how much time it took to call that API and the size of the payload returning. On that note, maybe a breakdown on how much time it took for AAD to return the token and the time required for the Service to return the call?
• Surface the JSON of the properties that will be stored in the page (to ensure everything is persisted properly)
• Page context information

I'll start with some questions here (and please ask more!):

• where do we want to surface this? is it ok if, initially we dump this information in a nice-ish way in the browser console?
• would it be better to have a dedicated area in the workbench that you can show/hide on demand and surface that information there instead?
• Do you think it would be useful for us to "signal" if something is different from generic pattern we would detect across all components used in your system (e.g. 75th percentile of web parts take 5 seconds to render and there's one that it takes 20 seconds) and, if yes, surface that type of information too?

Please, feel free to share your ideas ... and thank you for your time input!

[YannickRe]

I like all of that but first of all, I'd like the following for workbench: make it look and feel like an actual site in SharePoint.

• Having blank placeholders for site header, page header, left navigation (and ability to switch between Team Site and Communication Site look and feel)
• Support for application customizers
• Better support for theming
• Page width as it would be on a real page

I'd like all of the above before having more telemetry. I use Workbench for development, but I cannot ever be certain it works the same in a "real page". Preferably that anxiety is taken away first 😀

[nhe23]

Especially the different widths and the lack of layouts (one third, full etc.) make it very difficult to optimize webparts for these layouts.

[DPCamino]

At a minimum, the workbench must mimic the actual environment. That means have the option of actual full page mode so we can properly test SPA, etc without resorting to scriptlets or other web parts or manually changing container css.

Support for application customizers, definitely.

[jimmywim]

Just duplicating what I said on twitter (now that I'm at a laptop): I rarely use the SPFX Workbench when working on the platform, due to the lack of a site chrome.

I typically add my web part to a new page and use the querystring to enable debug (using the nice shortcut in the SP Editor browser extension).

I also use spfx-fast-serve for rapid recompilation & automatic page refresh - which is close to but not quite as near-instant as react hot module reloading - now THAT would be awesome.

My wishlist:

• Application Customiser support
• Bring in the site chrome, and have any workbench-specific chrome become part of the site chrome
• Hot module reloading
• A live view of the SPFX component's property bag, so we can keep an eye on values through the component's lifecycle
• Something to indicate which lifecycle functions are being fired when on the component on the page - saves having to add on console.logs everywhere to debug timing issues

[yhabersaat]

I'm not using the workbench or just for a specific context like first build or quickly see the render. I have two dev sites, Communication and Team for testing my developments so I'm 100% sure everything is working well on proper sites before production deployment.

As said before me in this thread and maybe the most important thing, the workbench should have the same behavior than a "normal" site (app customizer, theme, single page application, team vs communication, size, placeholders, etc.) and provide more advanced technical insights in the console or in a dedicated section as mentioned in the initial post is a good idea.

[patrikhellgren]

A lot of good things has already been mentioned and I agree with all of them, especially with the ones about prioritizing look and feel before telemetry. I would also like to add a few to the list:

• Make it possible to easily switch between all the themes available on the site.
• Make it possible to easily switch between different locales so we can quickly test localization without changing site settings, browser settings or user profile settings.
• Make it possible to easily switch between RTL and LTR so that we can test right-to-left and left-to-right behaviour without changing site settings, browser settings or user profile settings.

[joelfmrodrigues]

As mentioned by others, telemetry would be awesome but I think other elements should be improved before this to make the workbench more appealing to use. The Workbench Customizer web part solves some of the UI issues via very simple customisations when added to the workbench page (together with the web part to be developed), but I think this should be built-in instead of a custom web part:

• Preview mode by default instead of edit
• Page width in line with standard pages
• Option for full width

these are "quick wins", but as others said, things like theming and app customizers are a must and long due.

Regarding telemetry, I would prefer the info to be displayed somewhere on the page in perhaps a location that could be opened/closed as needed (even if the UI was basic). The console log is often full of stuff.
As an alternative, I think it would be great if the Page Diagnostics tool could be used for this as it would also create awareness for the tool.