I suggest you ....

Make it easier to develop javascript based web parts

Provide a better story than App Parts or Script Editors for custom web part development. I'd like to see a javascript based web part framework that would allow developers to build in their own "Editor Parts" using javascript and allow for serialization of web part properties (perhaps stored as JSON string).

Too much overhead with App Parts, and also they require iframe usage. Script Editors are a bit "wild west" and don't provide structure for editing custom properties.

219 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…)
    BrianBrian shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    16 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...
      • Juan PineiroJuan Pineiro commented  ·   ·  Flag as inappropriate

        Indeed! The Script Editor Web Part is pretty sad and yet it's what we seem to use the most. Create a client side API to Web Part Settings to allow us to add custom properties. IMO, The SEWP should be more an online IDE with a larger code editor window, intellisense, formatting, find/replace, etc. A feature to save the code into a deployable and re-usuable web part would be ideal too.

      • BrianBrian commented  ·   ·  Flag as inappropriate

        I elaborated on this a bit more in the Yammer Client Side Dev group. https://www.yammer.com/itpronetwork/#/threads/inGroup?type=in_group&feedId=6027656

        I'll copy the content here:

        A few different people throughout the community (including Rob Windsor ) have discussed using ScriptEditor and persisting properties into the script/markup itself tapping into the "Save" button click event to save web part properties. [b]My concern with these approaches is that they rely on undocumented APIs and/or UI elements that could change and break any solution not provided by Microsoft.[/b]

        The PnP AppScriptPart (https://github.com/OfficeDev/PnP/tree/master/Samples/Core.AppScriptPart) is good, and that's generally the approach I take, however with this approach the developer of the "web part" has to roll their own "editing/configuration" experience (if they want to offer one), which is not consistent with the OOB edit properties dialog. This could get confusing for content managers of sites.

        Ideally, I could define a script file, a list of dependent scripts (sp.js, userprofiles.js, taxonomy.js, etc), and perhaps, a custom "editor part" js function/file/page that would allow me to draw the configurable properties, capture the user input, and serialize it as JSON to be saved with the web part. During run/display time, it would spit out the configuration and the custom javascript could retrieve and render data as appropriate based on the configuration for that web part. I could then upload to .webpart the web part gallery of my site(s) and let the users configure the parts as they needed.

        I equate this to the Visual Web Part concept (aka Smart Part) from SharePoint past where I'd point at an .ascx file and it had the right hooks to customize display and edit experience.

        Bonus: some way to store only one copy of a custom script file and reference it from any site using a site relative path, similar to how _layouts works in On-Premise installations. For example, in each tenant, a single library that is the "shared" library. Maybe only tenant admins have ability to manage this library. Then enable a way to make it so that I could reference the same file in this library from different urls.

        For example: I create a custom .js file - MyCoolWebPart.js. I upload this web part to the tenant "shared" library. I can then access the same file from different urls, like:

        http://mytenant.sharepoint.com/_shared/MyCoolWebPart.js
        http://mytenant.sharepoint.com/subsite1/_shared/MyCoolWebPart.js
        http://mytenant.sharepoint.com/subsite1/subsubsite1/_shared/MyCoolWebPart.js

        and they all point to the same file. This way I don't need to copy it out to every single site collection/site. In alot of places I've seen the root site in a web application used for this, however, this falls down with multiple web applications (i know, not an issue for o365) and/or host named site collections.

        I know, I know...host the file myself in a custom site/server. In my current role I can do this rather easily, but I am sure there are many scenarios where this isn't as easy to do (thinking of smaller companies). Plus, it centralizes the assets and, assuming it's done using a (or similar to) a document library, you get the automatic browser cache busting when the file revs.

        I can imagine a "shared" structure that looks like this:
        http://mytenant.sharepoint.com/_shared/js
        http://mytenant.sharepoint.com/_shared/css
        http://mytenant.sharepoint.com/_shared/img

        with each having subfolders for each customization.

      • Piyush ShahPiyush Shah commented  ·   ·  Flag as inappropriate

        Totally vote for this. Even a newer version of script editor webpart would do which allows persistence of the personalised databag/propertybag via an encoded attribute value within the wrapper element of the webpart or queryable via the object model using webpartid. being able to detection of editing mode would be a bonus compared to current method of hacking hidden variables or ribbon elements. Webpart should also support azure cdn sourced js files

      • Scott CurrierScott Currier commented  ·   ·  Flag as inappropriate

        SharePoint vNext? - I'm not in a TAP program and do have the bits - would love to know how these things are shaping up...

      • Scott CurrierScott Currier commented  ·   ·  Flag as inappropriate

        Having constructed both Provider and SharePoint hosted Apps, I would love to see a story/framework having these elements.

        * Seamless iframe integration (or an alternative altogether) that easily merges within the current UI of the existing page without all the ceremony during construction - further abstraction of all the cross domain baggage

        * Frankly, the full page experience blows IMHO unless its a firm requirement of the project

        * Better story around themes/CSS when using Apps

        I could go on, but in general do I love App development despite the mess

      • Marc D AndersonMarc D Anderson commented  ·   ·  Flag as inappropriate

        I’m totally with you that this type of “non-app” approach needs to be a supported option. The reality is that apps/add-ins are overkill for smaller n, and are out of reach for citizen developers. An approach *like this* would be a step in the right direction if it were "supported".

      • BrianBrian commented  ·   ·  Flag as inappropriate

        Ideally the solution would also provide support for referencing out-of-the-box SharePoint javascript files (i.e. those in layouts) with cache busting built in, as well as "external" JavaScript files with ability to specify file loading order and/or where to load the JS (HEAD vs FOOTER).

      Feedback and Knowledge Base