In order to implement this type of solution, there are a couple options:
As a team, we have tried both approaches and we have some clients who prefer approach #1 and some that prefer approach #2. Here is a quick comparison of the pros and cons of each approach.
In general, our current approach is to start with approach #1 and then if we need to do so we’ll mature the code into #2 if the customization is complex, intended for mass re-use, etc. For something like a slider that is showing up on a single home page for one client, using a simple script editor is much simpler. However, if we were going to build a complex control that we wanted to deploy to dozens of clients, we would use approach #2.
Using the Script Editor
- Simple to deploy – just upload your JS file and stick your HTML into the script editor. You could also have your JS injected right into the script editor.
- HTML is rendered within the main page, e.g. there are no IFrames involved.
- Easier to make responsive than the App Part approach.
- Code isn’t packaged and deployable as a component
- Code cannot be added to the app store
- Lack of a configuration layer (e.g. you don’t have properties that your content editor can configure in the app part properties)
- HTML is not easily re-usable – you need some minimal amount of HTML and a link to the JS file in your script editor.
- Permissions are based on the context of the user loading the page. Lacks the permission model used in App Parts.
- Lack of integration with Visual Studio – you can edit the code but no built in deployment/debugging mechanism
- Lack of support for multiple “views”
Creating an App Part
- An App Part is a deployable component (code is packaged into a zip file) and can be uploaded to the app store (both the SharePoint app store or your internal tenant/farm app store)
- App Parts have a configuration layer that allows you to define configuration properties – very useful for specifying things like the list name, fields to map, locations, etc. for pulling data.
- App Parts are first class projects in Visual Studio
- Visual Studio integration with publishing of your app and debugging
- Support for multiple pages as views
- App Parts are versioned as components (e.g. the entire package of files making up the component).
- App Parts are rendered within IFrames.
- Deployment is slower – it involves several steps including deploying to the app store, then deploying to the site and then adding to the page. In our experience, unit testing is significantly slower because the deployment cycle is slower.
- Making App Parts responsive is much more complicated because they are hosted wtihin a fixed width, fixed height IFrame.
- No ability to change the code from SharePoint Designer