Extensions: Support Development in Local Workbench
Today, application extensions in SPFx (command sets, application customizers & field customizers) can't be tested within either the local or SharePoint Online hosted workbench. This is a bummer and a big step backwards to such a cool aspect to the development story with SPFx.
I get that you need a list to work with, but at a minimum, the workbench could have a static list with static data and no other functionality for us to test the customizations on.
My wish is that Microsoft adds support to the workbench for extensions before GA.
Thanks for your feedback! Although we appreciate your time and effort to give us this feedback, it’s not something we’re planning to do right now.
We have investigated this option and have concluded that only decent development experience for the SPFx extensions can be provided within the live sites, as instructed in the extension tutorials.
As we are planning to deprecate the local workbench starting with the version 1.12.1, we are not looking into provide this feature in future.
4 commentsComments are closed
Waldek Mastykarz commented
1) offline/airplane mode
2) using workbench as test bed. What if the list data could be loaded from a JSON file stored in the temp folder which we could modify if necessary?
Paul Schaeflein commented
#1. Airplane/Offline. For extensions that require a list, let me provide some mock data and you render it in a list with my extension.
#2. Workbench itself. With my #1 approach, a picker is not necessary. ;)
Thanks for engaging!
Andrew Connell commented
RE #1 - For *local* workbench, offline/airplane mode would be my preference. For "connected" (if developers wanted to use real SP data), I think requiring them to use the SPO hosted workbench / real lists is acceptable. Keeping the 100% offline mode for the local workbench is ideal as it facilitates full test coverage (unit | integration & E2E) without prompting for authentication, etc. With that being said, see 2B below as I'll contradict this last point...
RE #2 - Two ways to look at this IMHO... I'll answer as if I was the PM on the feature. Not trying to overstep my position in any way instead using this as a way to best communicate my thoughts "if I was in your shoes" :)
(2A) RE "pickers", that is how the current model works with CSWP's as you have to always add them to the page when testing with the workbench. Therefore, this would seem like a P1.
(2B) Ideally, there would be a way to launch the workbench and provision something... either programmatically or via a declarative JSON approach. Think about the CI/CD world - today it's not really possible (without a lot of unique UI instrumentation code) to fully test a SPFx component (CSWP / extension)... one can do unit testing with existing JS libraries, but you can't do full E2E testing because you first have to launch the workbench and then manipulate the UX to add the CSWP to the canvas.
Does that help?
Pat Miller (MSFT) commented
Just a few clarifying questions.
1 - Do you require offline / airplane mode, or is it ok for extensions to require a "connected" environment?
2 - Do you want to use the workbench itself as the test bed, or would it be better (or at least sufficient) for the workbench to have a series of pickers (what list and what field do you want to test on?) and a then it kicks off a request with the correct debug strings, etc?
Webparts 'tend' to stand on their own to some extent, but extensions seem to require more connection to the underlying app IMHO. I completely agree that we need to improve the dev cycle for GA - I just want to make sure we spend the resources in the right place.