0% found this document useful (0 votes)
11 views4 pages

Best Practices and Guidance For Cod

This article provides best practices and guidance for developing code components using the Power Apps component framework, covering areas such as TypeScript, JavaScript, and app types like model-driven and canvas apps. Key recommendations include avoiding development builds in production, managing resource cleanup, and minimizing API calls to enhance performance. It emphasizes the importance of adhering to established practices to improve usability, supportability, and performance of code components.

Uploaded by

rafael.silva1909
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views4 pages

Best Practices and Guidance For Cod

This article provides best practices and guidance for developing code components using the Power Apps component framework, covering areas such as TypeScript, JavaScript, and app types like model-driven and canvas apps. Key recommendations include avoiding development builds in production, managing resource cleanup, and minimizing API calls to enhance performance. It emphasizes the importance of adhering to established practices to improve usability, supportability, and performance of code components.

Uploaded by

rafael.silva1909
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 4

Best practices and guidance for code components created using Power Apps component

framework
Article
03/26/2024
10 contributors
In this article
Power Apps component framework
Model-driven apps
Canvas apps
TypeScript and JavaScript
Show 3 more
Developing, deploying, and maintaining code components needs a combination of
knowledge that includes the following areas:

Power Apps component framework


Microsoft Power Apps
TypeScript and JavaScript
HTML Browser User Interface Development
Azure DevOps/GitHub
This article outlines established best practices and guidance for professionals
developing code components. This article aims to describe the benefits behind each
so that your code components can take advantage of the usability, supportability,
and performance improvements these tools and tips provide.

Power Apps component framework


This section contains best practices and guidance related to Power Apps component
framework itself.

Avoid deploying development builds to Dataverse


Code components can be built in production or development mode. Avoid deploying
development builds to Dataverse since they adversely affect the performance and can
even get blocked from deployment due to their size. Even if you plan to deploy a
release build later, it can be easy to forget to redeploy if you don't have an
automated release pipeline. More information: Debugging custom controls.

Avoid using unsupported framework methods


These include using undocumented internal methods that exist on the
ComponentFramework.Context. These methods might work but, because they're not
supported, they might stop working in future versions. Use of control script that
accesses host application HTML Document Object Model (DOM) isn't supported. Any
parts of the host application DOM that are outside the code component boundary, are
subject to change without notice.

Use init method to request network required resources


When the hosting context loads a code component, the init method is first called.
Use this method to request any network resources such as metadata instead of
waiting for the updateView method. If the updateView method is called before the
requests return, your code component must handle this state and provide a visual
loading indicator.

Clean up resources inside the destroy method


The hosting context calls the destroy method when a code component is removed from
the browser DOM. Use the destroy method to close any WebSockets and remove event
handlers that are added outside of the container element. If you're using React,
use ReactDOM.unmountComponentAtNode inside the destroy method. Cleaning up
resources in this way prevents any performance issues caused by code components
being loaded and unloaded within a given browser session.

Avoid unnecessary calls to refresh on a dataset property


If your code component is of type dataset, the bound dataset properties expose a
refresh method that causes the hosting context to reload the data. Calling this
method unnecessarily impacts the performance of your code component.

Minimize calls to notifyOutputChanged


In some circumstances, it's undesirable for updates to a UI control (such as
keypresses or mouse move events) to each call notifyOutputChanged, as more calls to
notifyOutputChanged would result in many more events propagating to the parent
context than needed. Instead, consider using an event when a control loses focus,
or when the user's touch or mouse event completes.

Check API availability


When developing code components for different hosts (model-driven apps, canvas
apps, portals), always check the availability of the APIs you're using for support
on those platforms. For example, context.webAPI isn't available in canvas apps. For
individual API availability, see Power Apps component framework API reference.

Manage temporarily null property values passed to updateView


Null values are passed to the updateView method when data isn't ready. Your
components should account for this situation and expect that the data could be
null, and that a subsequent updateView cycle can include updated values. updateView
is available for both standard and React components.

Model-driven apps
This section contains best practices and guidance relating to code components
within model-driven apps.

Don't interact directly with formContext


If you have experience working with client API, you might be used to interacting
with formContext to access attributes, controls, and call API methods such as save,
refresh, and setNotification. Code components are expected to work across various
products like model-driven apps, canvas apps, and dashboards, therefore they can't
have a dependency on formContext.

A workaround is to make the code component bound to a column and add an OnChange
event handler to that column. The code component can update the column value, and
the OnChange event handler can access the formContext. Support for the custom
events will be added in the future, which will enable communicating changes outside
of a control without adding a column configuration.

Limit size and frequency of calls to the WebApi


When using the context.WebApi methods, limit both the number of calls and the
amount of data. Each time you call the WebApi, it counts towards the user's API
entitlement and service protection limits. When performing CRUD operations on
records, consider the size of the payload. In general, the larger the request
payload, the slower your code component is.

Canvas apps
This section contains best practices and guidance relating to code components
within canvas apps.

Minimize the number of components on a screen


Each time you add a component to your canvas app, it takes a finite amount of time
to render. Render time increases with each component you add. Carefully measure the
performance of your code components as you add more to a screen using the Developer
Performance tools.

Currently, each code component bundles their own library of shared libraries such
as Fluent UI and React. Loading multiple instances of the same library won't load
these libraries multiple times. However, loading multiple different code components
results in the browser loading multiple bundled versions of these libraries. In the
future, these libraries will be able to be loaded and shared with code components.

Allow makers to style your code component


When app makers consume code components from inside a canvas app, they want to use
a style that matches the rest of their app. Use input properties to provide
customization options for theme elements such as color and size. When using
Microsoft Fluent UI, map these properties to the theme elements provided by the
library. In the future, theming support will be added to code components to make
this process easier.

Follow canvas apps performance best practices


Canvas apps provide a wide set of best practices from inside the app and solution
checker. Ensure your apps follow these recommendations before you add code
components. For more information, see:

Tips to improve canvas app performance


Considerations for optimized performance in Power Apps
TypeScript and JavaScript
This section contains best practices and guidance relating to TypeScript and
JavaScript within code components.

ES5 vs ES6
By default, code components target ES5 to support older browsers. If you don't want
to support these older browsers, you can change the target to ES6 inside your
pcfproj folder's tsconfig.json. More information: ES5 vs ES6.

Module imports
Always bundle the modules that are required as part of your code component instead
of using scripts that are required to be loading using the SCRIPT tag. For example,
if you wanted to use a non-Microsoft charting API where the sample shows adding
<script type="text/javascript" src="somechartlibrary.js></script> to the page, this
isn't supported inside a code component. Bundling all of the required modules
isolates the code component from other libraries and also supports running in
offline mode.

Note

Support for shared libraries across components using library nodes in the component
manifest is not yet supported.

Linting
Linting is where a tool can scan the code for potential issues. The template used
by pac pcf init installs the eslint module to your project and configures it by
adding an .eslintrc.json file. Eslint requires configuring for TypeScript and React
coding styles. It can also be used to fix some of these issues automatically where
possible. To configure, at the command-line use:

shell

Copy
npx eslint --init
Then answer the following questions when prompted:

How would you like to use ESLint? Answer: To check syntax, find problems, and
enforce code style

What type of modules does your project use? Answer: JavaScript modules
(import/export)

Which framework does your project use? Answer: React

Does your project use TypeScript? Answer: Yes

Where does your code run? Answer: Browser

How would you like to define a style for your project? Answer: Answer questions
about your style

What format do you want your config file to be in? Answer: JSON (This answer
updates the existing .eslintrc.json)

What style of indentation do you use? Answer: Spaces (This indentation style is the
Visual Studio Code default)

What quotes do you use for strings? Answer: Single

What line endings do you use? Answer: Windows (This line ending is the Visual
Studio Code default CRLF line endings style.)

Do you require semicolons? Answer: Yes

You might also like