- June 25, 2020
- Posted by: Emmanuel Atemba
- Category: Microsoft, Office 365, Office365, SharePoint, SharePoint Framework
This is a four-part blog, and we will be exploring SharePoint Development with SharePoint Framework.
- Overview of SharePoint Development
- SharePoint Framework (SPFx) Development Environment Setup
- Your First SPFx WebPart
- Developing apps for Teams using SPFx
Previously in SharePoint, we had the content editor webpart, which was used to inject scripts or HTML Content on the pages. But the content editor had a problem; if you inject scripts or HTML directly, it will change the code you entered, or sometimes it would not even run, and sometimes it would give an error.
Due to these issues, two advancements were released; first, the Script Editor, which allows developers to add scripts into a page in SharePoint. You can as well add HTML Content and link your styles, scripts, or images from the Site Assets.
But the Script Editor has its challenges, which can primarily affect development time. For instance, the Script Editor interface is tiny text-area; therefore, looking for a specific section of code to edit is a huge problem. Additionally, you might get an issue with the Script Editor web part not showing or is missing in SharePoint Online Office 365, and one is required to change some settings at the tenant level; this can be a hustle. Lastly, code re-using is difficult, and one ends up with long lines of code that could have been achieved with just a few lines.
Secondly, SharePoint Add-ins. One most useful advantage of SharePoint Add-ins is that it has no access to the current DOM or connection. Also, it is external to the system. Because of this advantage, the End-user can easily install the “Add-ins” on the No-script sites and use it. SharePoint Add-ins runs in the iFrame. Iframes are slower than the Script Editor WebPart. IFrame has more robust security, which can be very useful for the end-users. That means the control has no access to their connection to office 365.
To overcome these issues, Microsoft comes with the SharePoint framework development model. And in SharePoint Online modern experience, we can use only the SharePoint framework for SharePoint web part development.
- SharePoint Webparts can be added to both modern Pages and the classical Pages.
- SPFx is Framework-agnostic, giving the developers the ability to use any JS Framework, common ones being ReactJS, AngularJS, and KnockoutJS. 4. It runs in the context of the current user and the connection in the browser.
- End users that are approved by the tenant administrator can use SPFx on all sites, including Teams Site, Group/Personal sites, etc.
- Develop for Teams
Benefits of using SharePoint Framework
- SPFx is safer
- Modern Development Tools
- Mobile-First Design
Because SharePoint Framework customizations run in the context of the current page (and not in an IFRAME), they are responsive, lightweight, accessible, and mobile-friendly. Mobile support is built-in from the start. Content reflows across device sizes and pages are fast and fluid
- Simplified Development
There is some work to do at the beginning of a new project to set up the SPFx structure to support reading from a remote host. An App Catalog must be created, as well as generating and uploading a manifest file. If the hosted content is connected with a CDN (Content Delivery Network), that will also require setup. However, once those structural pieces are in place, deployment is simplified to updating files on the host location. It does not require traditional code deployments of server-side code, with its attendant restrictions and security review lead time
- Smoother integration with external data sources
With SPFx, calls to data from external sources may be more comfortable since it’s web content hosted outside of SharePoint
This marks the end of Part 1. I hope the overview of SharePoint Development has been informative, and you will be ready to setup your SharePoint Framework Development Environment in the next post.