I suggest you ....

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.

69 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Andrew Connell shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    4 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Waldek Mastykarz commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        @Pat:

        #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  ·   ·  Flag as inappropriate

        Hey @Pat

        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  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base