[FEEDBACK] Let us know how you use the Script Editor Web Part

[chakkaradeep]

As part of the ongoing effort in SPFx, the product team is collecting details around the usage scenarios to see how we can help "citizen developers" in their journey to modern experiences. We are looking for the scenarios where you use Script Editor Web Part such as the various use cases, what kind of data is being shown, where the data is coming from (SharePoint lists, page, LOB apps etc.,), what is the actual functional/business scenario behind the usage of script editor and content editor web part.

Please add your comments and let us know how and why you use the Script Editor Web Part in SharePoint!

Thanks!

[sympmarc]

At Sympraxis, we use the SEWP or CEWP All The Time. We build real applications using these incredibly important Web Parts. I started doing client side development because in several projects back in the SharePoint 2007 days, we simply could not deploy any code to the server. (They were ahead of their time?) At the same time, people wanted real applications. So, whether it was truly kosher or not, the CEWP gave us a way to build these application without bothering the IT folks one bit.

Fast forward to 2017, and in many organizations, not a lot has changed. I have multiple clients who won't let me deploy anything to SharePoint Online. Client side development is still a key tool in my toolbox. "Why not use SPFx?", you ask? Well, I can't deploy anything. I also cannot built what I think of a Single Page Apps (SPAs) - applications that basically take over PlaceholderMain. With a little whizzy CSS @juliemturner built, we can even sweep the Quick Launch off to the side so we really "own" the page beneath the top nav.

So, what do we build? The easy answer is "What do you want?" The majority of applications we build sit on top of lists and libraries which hold content much like database tables would. By using a smart information architecture taking advantage of Content Type and Lookup columns, we build a related set of lists and libraries. Then we use client side code referenced in a CEWP or SEWP to haul that code into the mage to make magic.

These "applications" could be little things like something you might use a CSWP with a custom template for (but that actually a lot more work, IMO - I like to edit my JavaScript outside comments) to full blown dashboard or applications that drive an entire department or business's activities.

A few examples:

• An Asana-like overlay to tasks lists (which are actually a pain to work in if you have a lot of tasks or a big team)
• A scientific process tracking system which guides the scientist through experiments and collects the appropriate data at each stage, suggesting next actions
• A property management inspection system showing metrics and to do items
• An investment research portal to collect all research and disseminate to traders
• and so many more...

In many cases, we continue to use out of the box forms for the list and library content management - because they simply work. In other cases, we're building "forms" into our SPAs.

All this inside the humble SEWP or CEWP.

[chakkaradeep]

@sympmarc Thanks! Can you also tell us more about how you manage these scripts - as in, do you load JS/CSS files or write complete HTML/JS code in the block? I believe you showed me once how you use a library in the site to store and load scripts?

[bcameron1231]

As I've been using SPFx, I definitely see myself using SEWP/CEWP a lot less... because they essentially do the same thing -- Inject JS. However, there are many times where you want to have simple JS functionality on a page.... where building an entire SPFx project is overkill, for something that could be done in minutes using a SEWP.

[sympmarc]

@chakkaradeep Here's a post from @juliemturner that gives some of our thinking on code storage and management. (It's a bit old, and our thinking - and practice - has evolved.) We use desktop IDEs (editors, whatever you want to call them) and gulp tasks to push changes to locations in SharePoint. Very much separation of concerns: CSS in .css files, JavaScript in .js files, etc.

[dgusoff]

We do a lot of site provisionng scenarios where we populate home pages and other pages with functionality driven by SEWP. A lot of Search-driven rollups, carousels, Pinterest-style card layouts. We'll use Angular and/or React and REST API calls to fetch and render our data. Most of our data comes from SharePoint - publishing Pages libraries, document libraries, calendars, etc. We also do a fair amount of Yammer integration, via REST.

As with Marc's experience, our approach has evolved over time, but very often our web parts will only consist of a single Angular directive, with the supporting script files living in Azure blob storage and referenced via the master page or a custom action. Obviously the Modern experience changes the game for this approach.

We use Node/NPM/Gulp to develop our client side solutions and use and CI to push new builds (JS/CSS and supporting files) out to Azure blob storage.

[purtuga]

As with others here, I too have used the CEWP to improve and provide users with modern user interfaces that provide a superior user experience than SharePoint provides out-of-the box. Some of the benefits, IMO, are:

• Time to market (or to deployment)
  With CEWP, we are able to quickly apply changes and/or introduce functionality. Iteration of design and requirements often happens in near real time with the customer... All leading to happy users.

• Empowerment - Open to all
  Anyone can do this... That is a tremendous benefit behind these types of WebParts. It empowers nearly everyone user of SharePoint to be creative in coming up with solution to real business problems - after all, these are the folks in the front lines using the system.

• Solve the business need without the heavy deploy process
  Heavy applications with server-side dependencies take time to get through the process in med.-to-large organizations before they are actually deployed. This approach frees application developers from over complicated deployment processes and tries to move at the speed that the business is moving.

As a Web UI/UX Application Developer, the approach CEWP allows us to take advantage of is very similar to a traditional web app and to what SPFx is driving towards: your web app provides the interface only and consumes data from the public APIs from where it is hosted. As @sympmarc mentioned, I too have been building full scale client side applications and hosting them on SharePoint through the use of CEWP since SP 2007 - despite never having held a professional SharePoint title. Some examples:

• SDLC Requirements/Design documents management system
• Resource Booking system (rooms, projectors, etc..)
• Multi-Product support coverage and callout schedules
• Event Planning System with full commenting (conversation) and picture tagging
• Kanban Task Management System

All of these were done by using a WebPart page and addin one single webpart to it - a CEWP.

[sympmarc]

I think you guys at Microsoft underestimate the obstruction that is IT. The average person in a large organization has zero traction with them, and they can use these two Web Parts to accomplish things the business absolutely needs without going through processes which are usually convoluted and often unproductive - if we can even find a person who is willing to explain that the processes exist.

Things like SPFx, Azure Functions, etc. are absolutely the right path forward, but IT needs to change its spots or we're right back to the barriers we had with server-deployed code.

Note: For those of you in IT organizations that don't operate like this, congratulations to you for being a productive part of your organization. I'd still be interested to hear what your users think of how effectively you help them.

[casvaniersel]

Like most of the others here I think, regardless of the functional requirements, most customizations done with CEWP or SEWP are about combining data from SP lists or libraries and visualize them in a certain way. For my customers these are mostly dashboards on the welcome page of some site.

Reasons to customize:

• Lists in SP are used as a relational db. Data has to be fetched accordingly -> Custom code is needed.
• Search is indexing too slow, data must be available as soon as it's been entered -> Custom code is needed.

One major issue with all customization models in SharePoint is deployment if you're talking about enterprise customers (in my experience smaller businesses are more pragmatic about this). As @sympmarc points out, it's not because of the technology but because of IT departments that are stopping us from deploying stuff.

[faustocapellan]

My SharePoint team consists of just one person, me, and I do both roles Admin and Dev, which grants me no limitations to what I can do in my environment, but unfortunately most SharePoint admins don't have these freedom as pointed out by @sympmarc . I tried server-side code before with some consultants and that left me with no desire to do anything server-side anymore due to the complexity of deploying or retracting solutions, not including the downtime the farm would have to go thru. We wanted something simple and less time consuming so we started doing everything client-side, and using the CEWP and sometimes the SEWP, we were able to achieve better results when it came to deployment and application performance.

What do I use the CEWP and SEWP for? I use SEWP just to inject small code blocks, but for larger things, I use the CEWP. These large things vary from custom HTML forms to CSS for look and feel enhancements and JavaScript to add functionalities not available out of the box. And the biggest of them all is dashboards. Users want to be able to see data as soon as it's available, which is immediately.

[CloudDesignBox]

Where do I start?

Create Apps to validate and add/edit/read data in lists (Very much like the SharePoint Framework web parts). These are usually done through a content editor web part so i can load lots of required libraries like jQuery, momentJS, jQueryUI, bootstrap, chartJS, etc.

Also used it before to pull profile information into a web part such as profile picture, mysite links, etc.

Used it as a quick way to hide quick launch nav from a single page or apply a browser CSS fix - that's a pretty big one.

Looking forward to doing this all in typescript but it will take alot of time to move over apps with thousands of line of JS into typescript. I guess CSS fixes or changes in the new model will have to be using an application customizer which is very long winded....

Hope that helps!

[levesquesamuel]

I've been using CEWP since 2010 to achieve multiple scenarios

-People search with intellisense
-Paging (top & bottom with page number & page size)
-Image gallery viewer
-UI dom manipulation that can't be done with CSS
-Script execution based on audience E.g : Display welcome message to new employees
-Custom New/Edit/View form

Most of the time the data is coming from SharePoint.

CEWP are usually linked to a TXT file stored under /style library/ and referenced on specific pages.

Thanks!

[BobGerman]

I use CEWP to deploy "widgets"; this article explains how I manage the deployment: https://bob1german.com/2016/11/11/alm-for-widget-solutions/
My process has evolved over time but this gives you the general idea.

The use case is pretty much any custom web part or form: display SharePoint content in some unusual way; surface features from an LOB application; bring in other cloud data (oh no, not another weather web part! :-) ). I realized early on that the add-in model had its limitations and I started writing Widgets; a lot of others did this as well, as indicated in this thread.

At this point I personally prefer SPFx for this kind of thing but there are still reasons to use CEWP:

• Business user wants a solution and IT won't cooperate, so it needs to work for a site collection admin. This could be solved by a site collection level app catalog.
• Solution needs to work in an older version of SharePoint that doesn't support SPFx. Ideally this kind of solution is later ported to SPFx; I've had a lot of success doing that with 95%+ code reuse. This could be solved by back-porting SPFx (or a subset) to earlier versions of SharePoint, as was demonstrated last year at the EU SPC if I remember correctly.
• I need a form or SPA rather than a web part or extension - this could be solved by providing a general SPA template and a List-based SPA template for SPFx that allows writing SPAs for AllItems, New, Update, and Display views on a list.

If all these issues were addressed, I wouldn't need CEWP/SEWP anymore.

The other reason for CEWP/SEWP is when devs aren't comfortable with the SPFx stack. I personally don't buy that as a sufficient reason, but it's very real, and I've had a number of clients say that SPFx scares them due to the learning curve and perception that so many underlying dependencies could cause it to collapse. This kind of thing is no big deal to most commercial web devs out there, but a lot of folks in the SP community aren't ready to embrace TypeScript, WebPack, and all those nested npm packages that give you warnings that they're deprecated when you install them. Enterprise IT quakes in their boots when they see that!

So if you're looking for user stories for a modern CEWP/SEWP, I'd suggest the three "solutions" noted above as the 1st step - to minimize the need at all. Then, find a way to do something like the Embed web part only don't limit it to IFrame type embeds; a lot of the interesting ones won't work in IFrames. Provide tenant and site collection admin settings to allow all embeds rather than just IFrames, and let non-devs party on with regular JS embeds if they want to. That would also allow easy porting of "widget" type solutions without having to climb the SPFx learning curve. Meanwhile, SPFx would be more compelling due to the property pane, extensions, and general robustness vs. an ad-hoc widget.

My two cents - thanks for asking!