General thoughts on a modern script editor webpart

[patmill]

140 characters really isn't a sufficient amount of space to discuss the script editor webpart. It's an obvious thing to develop. The current implementation for classic pages is super popular and easy to bang out some code. I certainly have no problems with it in theory. In fact, it was the first webpart I created with SPFX drop 1.

It does present some interesting points for discussion. Why didn't we create and ship one ourselves? We figured a) someone would, because it's pretty straight forward and b) we think there is a better approach in the mid-to-long term.

As you mention - it's nice to do quick development prototyping. It's not really a great solution for something that authors can interact with. You basically give the "author" a render method. There's no configuration option given to an actual author for the most part (no real way to create a property pane), the persistence is code rather than data, and so forth (although I'm sure that if it was the only solution available that someone would find a way to incorporate both).

It's not (or at least shouldn't be) available for the noscript type sites (mysites, modern groups, etc.), so it's functionality is somewhat limited. On a related note, another issue is that if an admin decides to disable it, it disables all instances of the SEWP in the whole tenancy.

One thing we have considered as a sort of "bridge" between the worlds is a pseudo-script editor webpart where the code itself is stored in the manifest. This could give a streamlined development process (for a certain class of webpart where you don't need the full power of SPFX or its toolchain; and you wouldn't be able to use the full toolchain either). So the app package would simply contain a webpart component with a manfiest that embeds the render script in it. At runtime, the ModernScriptEditorWebpart executes, pulls the code from the manifest, and executes it. That would give some isolation as far as approval, monitoring, disabling and such, while still allowing for a simpler (in all senses of the word) development model.

You would likely lose the ability to do things like have property panes, bundling, webpack, and so forth, but again - for that class of webpart that doesn't need them - that's quite ok. The target audience of this is also likely to be a different class of developer - one who likely has no idea who the tenant admin is, so you would want to have a workflow that takes the code, packages it up, submits it to an admin for approval, allows you to ping them, and so forth.

If only we had infinite resources. :)

[kevmcdonk]

What about a content editor type web part that links to a file where you can host an HTML? You can then sync that library and work offline, even including all the web pack and other node/gulp/etc goodness. Useful for cases where you have a single app that only needs to exist on one page.

[StfBauer]

Script Editor web part was always the worst choice of two options.
To embed custom code onto a page, I always used a content editor web parts and linked to an HTML file stored in site assets.
This file was never loaded as an iframe instead, the code was directly embedded on the page. If the code needs to be changed in future, you only had to update the HTML and all instances of the web part automatically were refreshed.
For testing scenarios, this HTML snippet could be easily embedded on an HTML page as well as the Workbench.
The embedded file can even be code check during the embedding process. For example, have HTML and BODY tags were removed or are script sources coming from an allowed source (HTML Field Security).
Maybe in future, it is possible to load small React Components directly this way.

What even the future will bring, please don't let it be a script editor web part because it is simply not manageable and cause a lot of forgotten artifacts on the pages.
In case an HTML snippet have been deleted even an error can be shown on the page.

Let's burry the old script editor web part, like SharePoint Designer - Dead and gone, but please replace it with something more appropriate to manage and use.

[Brentless]

I am not a "developer" but I know JS, HTML, and CSS. I still use SPD and SEWP every day in SharePoint Online.

I don't disagree that SEWP has weaknesses, but it also has many strengths. I think the Vesa and others have greatly overexaggerated what "citizen developers" are, because they are not developers at all. Joe Citizen Developer can (1) add a web part and (2) paste some code, but at the end of the day, these are not people that are coordinating with enterprise development teams to accomplish something. (Maybe some are, but I would speculate the majority arent and won't).

I can't even begin to quantify the value within our organization that being able to do these things in SEWP have brought.

Our "developers" are focused on true custom applications, mostly customer facing, and for our organization, those things don't integrate or live in sharepoint. (Again, some maybe are, but I speculate the majority arent). So now, in order to continue to do this stuff, I have to "go back to school" to learn what the heck all of this gulping and yo-ing and typescript and everything else. What would take me 5 minutes to do in a quick script now takes forever, and hundreds of lines of code, and all kinds of tools that I dont know what they are (and it isnt my job to learn and become an enterprise developer).

I think the pendulum has swung too far in trying to protect users from themself, and by making developers the "gatekeeper" to add quick and easy functionality, I strongly believe that this will stifle innovation.

Simply put. Time to learn and build the skills to accomplish these simple needs will cause us to keep using Classic mode, and limit our expansion into Modern UI.

[johnnliu]

@StfBauer I've always gone for the Content Editor - just works everywhere, even much older SP on-premises environments.

In the webpack world though, since everything is javascript - if the final output is a few js files, it did occur to me that a script editor would work quite well now in SPO. Also, I think a script editor now should points to the CDN and is decoupled from the document library that I'm publishing to.

Which gets me thinking - if MS releases a "modern script editor part", it could be configured to only allow scripts from the current tenant's own SPO-CDN.

e.g. https://publiccdn.sharepointonline.com/johnliu365.sharepoint.com/

So if the business wants to review into the approval of the scripts that could be done and controlled from the nominated document library.

[wobba]

@StfBauer and @johnnliu I could have added functionality to point to a file instead of pasting in the code. Sort of same same in terms of functionality - and I might add that one to give a choice. As a sample it's the same - would be one more step to load the file, vet and inject it into the DOM element before parsing the code like I do now.

@patmill I do like the approach as to bundle script in the manifest to have it packaged up a a first class citizen doing one thing only. For parts needing a proper edit experience with properties for some end/power user I 100% agree that the parts should be properly made, like the oob ones.

Where script parts makes sense for me is where I as a developer/consultant/provisioning engine set up a page for you, and want to add functionality to the page up front. This could be a bootstrap tour explaining UI elements, it could be a fat red button saying "Disclaimer", which opens up a new page, or showing the current weather/time... you get the idea. And the code per part is so small/or re-usef that I don't justify the time building up a full project and have it deployed for each single scenario.

Of course as you know, in non-script sites, this provisioning stuff is currently not an issue as we cannot:

• programatically create new pages
• programatically add SPFx parts to a site( afaik?)

both features I really hope is on the roadmap.. in a plain team site I can at least programatically create new modern pages and pre-populate them with parts.

As for the governance - you put out the guidance on how to block parts from being run on non-script pages. This is a good thing indeed, but puts the power with the developer. This feature should be an option in app catalog for the IT admin installing the page imo. If the admin say "block from non-script sites", the manifest should be manually updated with the needed steps. If we could have a mechanism for allowing parts on a per site collection basis - that would add even more control.

If someone adds a part to a site, they have to request permission for it to be added. Full flexibility on how parts are made, and where they are allowed to be used.

[patmill]

@wobba - On the admin override - yes. Already there, just didn't mention it in the original doc. I've updated the document to mention that the property is promoted into a field on the component manifest list, and the admin can change it. When they change it, all instances configured on a noscript site will stop working. The dev states it in the package (since they are the ones that should really know what the webpart is doing), but the admin has final control.

[wobba]

@patmill I wouldn't trust me, the developer, as I argue that what I create should be used everywhere. Thus having the admin property is very cool. Time to educate IT that they get some control and saying :)

[amishra0909]

Thanks for the feedback everyone. Closing this issue.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues