Overview
As the capabilities in the Microsoft Power Platform have matured over the last couple of years, Thrive has spent considerable time delivering business process automation solutions using the tools in the platform. With Power Apps, Power Automate, and Power BI, the platform allows us to accelerate the digital transformation process for our customers using the low-code capabilities in the platform. However, when requirements get complicated, a better approach may be to build your form using the SharePoint Framework (SPFx). This is especially true if you are dealing with large amounts of data, fast load time of the form is critical, or the UI requirements are complicated. Using SPFx does require development experience, but with the right skills, you can quickly build out custom forms that can provide a better solution.
The table below provides a detailed comparison of building your form in Power Apps versus using the SharePoint framework. We have also provided a summary of our findings at the end of this post.
Detailed Comparison
| Power Apps | SharePoint Framework | |
List Thresholds |
Currently, when a list has threshold problems, there is no way to easily work around them in Power Apps. The Power Apps will immediately break if already published and will not allow you to publish or save it. All submissions will break. | Structuring the data or applying filters makes it easy to work around List Thresholds and retain functionality. |
Performance |
Even with small-scale forms and applications, the load times for Power Apps can be relatively lengthy. | Performance is exponentially better than Power Apps. Small or large applications will load quickly and navigation in large applications is also extremely fast. |
Simple Forms/Applications |
For forms that we just want to add a couple of easy conditionals, set up some formatting or styling, and so forth, Power Apps is probably the way to go. It requires little to no development knowledge and allows for further customizations by Power users. | For simple forms or applications, we may want to stray away from an SPFx solution. The development overhead and time spent would most likely outweigh the benefits. |
Large Forms/Applications |
Power Apps can get very bogged down by large applications that contain paged navigation, a lot of conditions, several lookups, etc. Maintaining connections between pages, altering conditions, implementing validation, etc. becomes very difficult. | Large forms and applications can be constructed to be exactly what meets the needs of the business. Inline field validation, paged navigation, conditions, etc. can all be implemented with ease. Performance is also fantastic in any SPFx application. |
Dev, Test, Prod |
Power Apps becomes tricky if you want to try to have a development stream. If you have a Power App that is integrated with a SharePoint list or library, it cannot be exported or migrated anywhere else. You would need to continuously rebuild the app from scratch and reconnect all data connections for this work. Canvas apps do allow for exports, but the amount of configuration required for each installation can be painstaking. | Seeing as SPFx solutions are packages, they can be deployed at a tenant wide level or per site collection. This means you can easily spin up a development, test, and prod site collection and have a development stream that can publish updates to any one of these environments with ease without affecting anything you don’t want. Pipelines can be established to further simplify the development stream. |
Migration |
As stated in the previous point, migration can be very difficult or even impossible with Power Apps. | Given the nature of SPFx solutions, migrations can happen with little to no effort moving between site collections, environment, and tenants. |
Validation/Conditionals |
Conditional and validation logic is certainly possible in Power Apps, but only to an extent. Certain fields do not have the innate ability to filter out things such as special characters and implementing logic to do so is tricky. In some cases, the logic may not even have the ability to be implemented. Conditionals are also implementable, but take time and can be very reliant on form loading factors. Rules were removed so there is no central location to manage all of your logic. | Literally any form of conditional or validation is possible in SPFx. Real-time/async validation is implementable. Regex, string validation, number validation, etc. is all easily implementable and scalable. Conditional logic can easily hot-swap visible components to the user. |
Data Connections |
While data connections to other applications in Office 365 are easy enough to set up, they cause some unintended side effects that may result in an undesirable user interface. For example, if you wanted to pre-populate a Manager field in Power Apps, you can do this by adding the Office 365 Users data connection. However, when you add this data connection, it will prompt the user to allow access to this when they load the Power App. This will occur each time they load it if their cache has been cleared and in other instances as well. | While data connections require a bit more set up in SPFx, they can be tailored to do exactly what you need them to do. The sign-in prompt that was mentioned in the Power Apps version of this functionality is no longer an issue. Data connections will migrate with the application should you decide to move it. By default, connections to Teams, Graph, SharePoint, and more are relatively preconfigured for you when creating an application in SPFx. |
Redirects |
Currently, redirecting applications on submission is not possible from Power Apps. This can cause a lot of headaches, particularly in SharePoint integrated Power Apps. | Redirects are completely possible in all manners within SPFx. |
SQL Connections |
Connections to SQL databases are available from in Power Apps. Depending on what needs to be done with them, you may or may not want to use SPFx (driven by the complexity of the app). | SQL connections are also easily implementable in SPFx. They can integrate with non-standard SQL connections such as Azure Cosmos DB, AWS, Firebase, NoSQL DBs, etc. |
Customizations |
Depending on what needs to be customized, you may or may not be able to complete the task in Power Apps. While they give you a wide range of customization options in Power Apps, you will still encounter some limitations in terms of styling, sizing, resolution, etc. | There are essentially no limits to the customizations you can do in SPFx. |
Responsiveness |
While Power Apps can and will work across platforms, it still has a wide range of issues with responsiveness across browser sides. One area of note is when using People Pickers, Date Picks, and Multiple-Choice fields. These components will often be inoperable on smaller devices. In addition, embedded Power Apps will often have scrolling issues where a user cannot scroll to the very bottom of the app on smaller devices. This is currently a known issue. | SPFx applications can be made to be 100% responsive across devices. In addition, SPFx grants the ability to design per device or screen size. For example, you could create a design for phones, a design for tablets, and a design for PCs all in one application. |
Data Load |
Data loading can be tricky in Power Apps. If you are trying to execute actions based on pre-loaded data, there is not much in terms of something asynchronous that will await the response. Many different issues can come up in things like conditions based on pre-loaded information as the information is not ready to be consumed. | Data loading is no issue. Async/Await functionality is easily implementable to ensure that you have the information you need when you need it. |
Summary
Use Power Apps if…
- You do not require storing more than 5,000 records
- The speed of the forms is not a significant consideration
- Your forms are relatively basic, without complex repeating sections or business logic
- You do not need to promote the forms through Development, Test, and Production environments
- You do not have complex conditional or validation logic
- Your forms do not need to redirect to a custom location upon completion
- Responsive design across numerous browser configurations is not critical
- You have power users who can maintain and modify basic forms and functionality
Use SharePoint Framework if…
- You need to store larger amounts of data
- Fast form load and navigation time is critical
- There is complex logic and/or UI design involved
- You need to support a full Software Development Lifecycle or migrate the form to various locations
- You want complete control over the responsive design to support various browser configurations
- Having seamless integration into Teams and/or SharePoint is important
The SharePoint context object can give you a lot of crucial information about the user currently logged in, the page that a user is on, templates being used, and more.
By default, when working in SharePoint Framework, by default, you will have access to the context object within the most parent component.
In this case, the component is the BaseClientSideWebPart component. For the most part, we will want to keep each component in our projects clean and, as we don’t have access to state in this component, we will want to pass context down to the next highest child component. This child component will technically become the parent component to every other component in our project as it will handle most of our data operations (this can also be a service if you would like).
Passing the Context Object Down
A very important use case for employing the context object is being able to utilize the spHttpClient that will grant us access to SharePoint’s REST API in the context of the currently logged in user.
The easiest way to do this is to pass the context object as a whole down as a member of props. When creating a project in SharePoint Framework (as a Web Part project), it will generate a main .ts file (the BaseClientSideWebPart) and a single component with the .tsx syntax.
In addition, a Props file for that .tsx file should also be available. We will first want to add a line to our Props file for the context object we will be passing. Simply define “context: any;” in the Props file, and we should be done here (as shown below).
Now that our Web Part has the property available, we can head over into our root .ts file to pass the context object down. To do so, simply define the prop “context: this.context” in the React.createElement statement (as shown below).
Our context object should now be available in our SPFXWebPart. To test this, we can make a simple REST API call to get the current site’s lists. Add the code shown below into the constructor statement of your web part (you may need to add the constructor if you did not already).
The site URL variable can either be defined or replaced with plain text. It can also be removed completely to make a relative call to the site it is deployed on.
If the call comes back with the expected data, you have successfully passed the SharePoint context object down through your web parts in SharePoint Framework.
Interested in this solution for your SharePoint investment and working with the Timlin team? Request a 30-minute free consultation here.
Something that you’ll notice with SharePoint Modern pages is that they currently limit you to a restricted with container centered in the page.
The modern experience does have a full-width container on specific pages, but only certain web parts can be added to this area (the Hero and Image webparts). With SharePoint Framework, you can make web parts that are marked as being eligible for the full-width container but that doesn’t help you if you want web parts that already from with the Modern experience.
Making your Modern Pages Full Width
Before we continue, I want to make sure that it is noted that the method detailed in this article is not supported by Microsoft at this time. However, the method used will cause no harm to the environment or your page structure and is merely an easily implementable web part.
To start, create a new SharePoint Framework project using the yeoman generator. If you have not done this before, please refer to the documentation here for instructions on how to do this.
We are going to use this web part globally across the tenant so ensure you give it a name you’ll recognize. The name we will give it for this exercise is “Full Width Web Part”.
Once all of the solution files have completed downloading, open up the solution’s code with “code .” in your command prompt (while in the directory the project was created in). This will open the solution inside of Visual Studio Code. To start, we will need to install the npm package for jQuery.
To do so, type “npm install jquery –save” in your command prompt. This will download and load the package into the dependencies of your project.
From here, we will want to import this dependency into the root BaseClientSideWebPart of our project. Add the line “import $ from ‘jquery’;” after the last default import statement in the file, as shown below.
Next, we merely need to add a single line to the render statement on this same file. Add the line “$(“.CanvasZone”).css(‘max-width’,’100%’);” right before the ReactDom.render statement, as shown below.
At this point, we’ve done all we need to do in the code. Bundle and package the solution for deployment in your SharePoint App Catalog (using gulp bundle –ship and gulp package-solution –ship).
*Note: To use the –ship production pipeline, you will need to have enabled the public CDN for Office 365 in your tenant. If you have not done this or are not sure if it is enabled, review the instructions here.
Once the package is deployed, simply add the “Full-Width Web Part” that we just created and deployed to any modern page that you want to have a full-width container and we are good to go.
