Custom code components - go beyond power pages limitation

Life without code components

Power Platform has been evolving quite rapidly as Microsoft continues to invest in the area. In this article the following will be discussed:

• Power Apps Portal, recently renamed to Power Pages.
• Power Apps component framework (PCF), or also known as custom code components.

More and more enterprise and government customers seek to modernise their legacy applications and aim to bring everything together into one platform. Websites and portals are no exception to this. Microsoft bought ADX portal studio in 2015 and rebranded it to become the portal capability tied to Dynamics 365.

JQuery / JavaScript has been the main tool of doing portal customisation. Microsoft also introduced liquid templates for server side processing to move away from developing any custom server side (MVC) code. However, with any low code platform, sometimes clients requirements demand more to what the platform is capable of.

PCF / Custom code components

Integration with other systems can quickly becomes a challenge and Microsoft acknowledged there needs to be a better tool to develop custom code especially across different Power Platform interfaces, not just the portal.

Developers have been incorporating modern JavaScript frameworks manually into the Portal JavaScript section to workaround the challenges, but fortunately Microsoft introduced Power Apps Component Framework to address the situation better, and React has been chosen as the recommended framework moving forward.

Going forward: At GA, React and Fluent UI will be the recommended and default way to create all code components. We recommend starting to evaluating React + Fluent controls for building Power Apps code components.

PCF is designed to work across every Power Platform interfaces such as Model-driven apps, Canvas apps and Portal albeit there are still differences of what is supported for each interface.

PCF for Portal used to support only field-bound forms. With the new ability of rendering PCF via liquid template, this opens a lot of possibilities as it can live outside portal forms and be rendered anywhere on the site.

Use cases examples

Payment gateway integration

• External users needs to be able to do payment via chosen payment gateway while maintaining PCI compliance.
• Backend office staff needs to be able to make payment on user behalf in model-driven app.

Without PCF, custom JavaScript code needs to be developed and maintained twice in both interfaces.

Large file upload integration

• SharePoint document integration has a limit of 25 MB size per attachment.
• Azure Blob storage has a limit of 125 MB size per attachment.

When the requirements cannot be satisfied easily (e.g. larger size or more file security), developing PCF can help to meet these requirements.

Considerations

With great power comes great responsibility

• Security must always be at the back of developer’s mind while building PCF. All code inside PCF is your own code, thus Microsoft is likely not be liable for any security issues that stem from the PCF component.
• As PCF is just a wrapper around your client side code, anything is visible on the browser. Any sensitive information and processing should be protected (e.g. using API integration that hides the functionality from the browser).
• PCF is meant to work across all Power Platform interfaces, so avoid any unsupported workarounds such as modifying things outside the component. Microsoft has produced best practices around PCF development.
• As PCF is still evolving, expect there are some things that can still pose a challenge, mainly with the integration with Dataverse (e.g. fields such as lookup is not supported yet to bind). However, with custom code there is likely to be a workaround that can be thought of.

Conclusion

For developers that come from custom development background, this is a much needed and welcoming feature of Power Platform. Low code platforms are great for rapid development and business benefits realisations, but sometimes they are still not be able to cut complex requirements easily.

Fusion development would be the reality moving forward and as Power Platform becomes more mature, there is no doubt it will be Microsoft’s greatest investment to come.