Power Apps- 摆脱内联代码
Source: Dev.to
(请提供您希望翻译的具体文本内容,我将为您翻译成简体中文,并保留原始的格式、Markdown 语法以及代码块和 URL。)
1. Inline Code
看起来像什么
您可以直接在元素中嵌入 JavaScript:
Click Me
或者,在 Power Apps 中,您可以直接在属性上(例如 OnSelect)编写公式。
为什么它受欢迎
-
即时上下文 – 代码位于它影响的组件旁边,便于一眼就能理解。
If(vsText = "Hello World", RGBA(189, 178, 176, 1), Color.Red)
-
可移植性 – 在应用之间复制粘贴组件时,逻辑会随之一起迁移。
权衡
代码审查
当每个公式都是内联时,应用的逻辑没有单一的“全局视图”。您只能在许多屏幕和控件中逐个寻找,只能一次看到很小的代码片段。
FYI: 我构建了一个网页应用,可以将 Canvas 应用中的所有代码提取到一个文档中——见 .
代码复用
好的代码应该是可复用的。内联公式会迫使您在多个控件之间重复相同的逻辑。
示例: 在七个不同按钮(新搜索、下一页、…)中需要使用的 SQL 查询连接器。每个按钮都包含相同的代码块,只是输入不同。
何时使用内联代码
| 规则 | 描述 |
|---|---|
| 从不复用 | 该逻辑不会在其他地方需要。 |
| 单一操作 | 公式执行一个简单操作(例如单个 Patch、基本计算)。 |
如果代码包含多个逻辑步骤(例如 patch + reset + update),请将其移动到可复用的块中。
2. 用户自定义函数 (UDF) 与行为 UDF
Power Apps 现在支持 App Formulas(也称为 UDF)。Behaviour UDF(Microsoft 的术语)本质上是一个子例程——执行操作但不返回值。
区别
| 方面 | UDF | 行为 UDF |
|---|---|---|
| 作用域 | 限定在函数内部;可以读取/写入变量和组件。 | 相同的作用域,但仅用于副作用。 |
| 触发方式 | 声明式——引擎决定何时重新计算。 | 命令式——显式调用(例如,从按钮)。 |
| 输出 | 返回一个值。 | 返回 Void(无值)。 |
简单示例
UDF – 返回值
AddOne(num : Number) : Number = (
num + 1
)
Behaviour UDF – 执行动作
AddToVar(num : Number) : Void = {
Set(viNum, viNum + num)
}
第一个将提供的数字加一并返回;第二个更新全局变量。
创建方式
两者均在 App → Formulas 中定义:

语法略有不同:
FunctionName( inputName : InputType ) : OutputType (
// Your code here
)
UDF 使用圆括号 () 作为函数体,而 Behaviour UDF 使用花括号 {} 表示它们执行操作且不返回值。
3. 何时使用 UDF / 行为 UDF
| 情形 | 推荐做法 |
|---|---|
| 可重用逻辑(由多个控件或屏幕使用) | 创建一个 UDF 并在需要的地方调用它。 |
| 副作用操作(设置变量、导航、调用连接器) | 使用 Behaviour UDF 以保持调用公式简洁。 |
| 复杂计算(会使内联属性变得凌乱) | 将计算移入 UDF 并引用其结果。 |
4. Functions in Data‑versus‑Flows
(Placeholder for any additional discussion about using functions inside Power Automate flows or Dataverse‑side logic.)
TL;DR
- Inline – 快速、针对特定上下文,但难以审查和复用。
- UDF / Behaviour UDF – 集中、可复用且更易维护;对任何重复出现或会使内联公式变得笨拙的逻辑使用它们。
通过遵循这些指南,您的 Power Apps 将保持可读、易于维护且具备可扩展性——就像将 JavaScript 从内联 “ 处理程序迁移到外部脚本文件一样。
5. 示例 UDS
SubroutinenName( inputName:inputType ) : Void {
}
6. 可选和多个输入
AddTogether(num:Number, num2:Number) : Number = (
num + num2
);
7. 简单 UDS 示例
AddOneToVar() : Void = {
Set(viNum, viNum + 1);
};
8. 何时使用 UDF 与 UDS
正如你所见,尽管 UDF 非常有用,但它们不会显著改变我们编写应用的方式,因为使用场景相对较小。相反,UDS 更加强大,因为我们可以沿袭 Web 开发者开创的路径。
8.1 何时使用 UDF/UDS
我的观点是:我们应该更多地使用 UDS。根据使用内联代码的两个条件,其他所有代码都应移到 公式 栏并作为 UDS 调用。

- 复用 – 如果你计划复用这段代码,请将其做成 UDS。
- 复杂度 – 如果一个事件属性包含多个 Power FX 函数,请将其做成 UDS。
总会有灰色地带。例如,下面的代码是否应该移到 UDS?
UDS() : Void = {
Patch(dummyData, {ID:1}, {Title:"test1"});
ResetForm(Form1);
};
它执行了多个 Power FX 函数,但只有两行。为了可读性和明确的标准,我会将其移到 UDS。
关键注意事项
- 命名 – 使用描述性的名称;如果函数不可复用,请在名称中加入组件名。
- 注释 – 如果可复用,请在注释中列出使用它的组件。
9. Functions in Dataverse & Flows
Dataverse Functions
- 在 服务器 上使用 Power FX 运行。
- 通过简单的 API URL 提供可复用性,可从其他应用、流程和专业代码解决方案中调用。
考虑因素
- 仍然存在 bug;微软的关注度似乎在下降。
- 需要 Premium 许可证。
- 最大运行时间:2 分钟。
- 同步执行——调用者必须等待完成。
仅在需要在多个平台上运行相同代码的特定场景中使用 Dataverse 函数。
Power Automate Flows
- 添加了非 Power FX 的技术层,但每个 Power App 开发者都可以使用 Power Automate。
- 比原生 Power FX 慢,但提供:
- 访问众多连接器。
- 非用户(服务)连接。
- 委派——应用可以在流程后台运行时继续操作。
典型使用场景
- 不应阻塞 UI 的长时间运行任务。
更多细节,请参阅我的博客:
- Instant Dataverse Functions & Low‑Code Plug‑ins
- Power Apps – Client or Server Side?
- How to – Power Apps Getting Polling Update from File Upload
10. 最后思考
热点观点:将代码从内联表达式移到块(UDS)中。 我预料会有反对声音,这很正常,但请考虑:
- 这不是非此即彼的规则——还有很多灰色地带。
- 改变需要时间,但一旦习惯后,可读性和可维护性都会提升。
- 专业代码解决方案往往能为我们处理繁重的工作。