TECH TALK｜微软Canvas App实战踩坑指南.1：undocumented feature

0. Canvas App是什么？本文写的是什么？

Canvas App是微软Power apps的一部分，致力于低代码、拖拉拽构建App的一种昂贵的，新鲜的玩法。至于他的好处，自行咨询微软的顾问吧。需要知道的一点是，这东西价格感人：目前是按每个终端用户每个月收取40美元。当然，你有更便宜的选择，不过用起来就......呵呵呵......

本文记录的是实战中遇到的一些undocumented feature，即文档里没提的那些事！

文档里没提意味着什么呢，呵呵呵......自然是大坑啊！

如果你正准备跳进这个坑，不妨阅读本文。共2600字，大约需要15分钟。

1.变量赋值的第一个坑

这里先给没接触过CanvasApp的人简单介绍一下。使用Set设置全局变量，使用UpdateContext设置局部变量，这都是文档里有的。如设置全局变量A为100：

以及设置局部变量B为100

那么，如果我有一个类似于这样的变量X，其值为 {A:100,B:false,C:"stringC"}的话，我企图对其中一个成员属性A赋值，应该怎么做呢？

根据文档，你需要这样做：

但是，这样你可以设置 X.A 为200了吗？

呵呵呵，大错特错了，把文档往前面翻一翻，再仔细读一读！嗯，它使用的是Patch的返回值，而不是更新原值哦！

因此，正确的做法是声明一个变量（下面以局部变量为例）

这样，你声明一个Y，其值为X改变了A成员属性之后的那个东西，即Y等于。恭喜你，执行了这句之后，你拥有了X和Y两个变量。至于X，它依然还是

你都有了Y了，赶紧忘了她（X）吧！

当然，如果问题到此为止，显然不足以称为undocumented feature，真正的坑还在后面：

假设上面的X是一个从数据库里查出来的记录，例如一条Product（商品）记录吧。那么更新后的Y呢，并不能被当作Product类型使用！虽然他们所有的成员属性都是一样的，类型也都是Record，但是架不住Form表单控件就这么认死理！

X不让改，而Y不是适当的类型，这还怎么玩？嗯，八仙过海，各显神通吧，反正文档里是真没提的！呵呵呵......

2.变量赋值的另一个大坑

当你一次性声明多个局部变量，你可以这样写：

如此，你可以得到3个局部变量A、B、C。官方文档也就到此为止，不再深入了。

但是，坑都在文档外哦！如果你的A、B、C是查询结果集呢?请看如下代码

当你企图将查询结果A做排序得到B，然后取B的首条得到C，呵呵呵，你会发现后两者很可能是空的。原因在于，查询是异步行为，赋值语句是同步行为。执行到B和C的时候，A很可能还没执行完呢！

从坑里爬出来，你需要分别写成三个赋值语句，以分号隔开。代码如下

难到不难，可这么做文档里没提，走弯路是免不了的啦！（幸好有我指点，是不是考虑给个赞？）

3.变量赋值的一个天坑

上面的两个问题多多少少还算是有迹可循的，下面这个问题就比较无语了。

你可以根据文档介绍，轻松对一个数据源赋值，这事属于基本增删改查操作，没啥好说的。但是你不知道的是，在CanvasApp中，你可以将一个值更新为一个新值，或者将一个null更新为值，但是，但是，但是......

你无法将一个值更新为null（CanvasApp中叫做blank，此处以大家熟悉的叫法称null）

这个就太销魂了点，不光文档里不提，而且运行是不报错的——仅仅只是不产生更新效果。

想要将数据源更新为null值，呵呵呵，跟我来

在项目设置里找一个名为“公式级的错误管理”的“试验性的功能”（Experimental Features）。打开它，就好了。

至于为什么是试验性的功能？我也不知道啊，从2018年开始才有这么个东西的，之前还没有呢！2年多了还是实验性，估计背后还有隐蔽的深坑。不过还是要感谢微软，至今还没取消此功能，否者，画面太美我不敢想。

那为什么叫做“公式级的错误管理”这么生涩的名字。看名字和null八竿子打不着啊？估计，微软的人在做一个和错误管理相关的功能的时候顺手一起做的吧，就是这么随性所至！

下面的链接是该功能在社区里的介绍文章。不是正经文档，但是聊胜于无，找到这犄角旮旯里也是很不容易了，各位看官不给点个赞么？

New Experimental Feature: Error Handling and Writing Null values to databases | Microsoft Power Apps

4.无法正确赋值的Form（表单）控件

Form是一个非常常用的控件，可以一行提交代码搞定数据库更新、创建的操作。这东西方便是方便，但是其对象模型就不那么友好了。

官方文档里秉承着“我告诉你能做什么”的原则，刷刷刷地一大片操作方式，但是偏偏不告诉你“不能做什么”，这就很监介（尴尬）了。

比如，你企图对表单中的控件赋值，看起来好像也生效了，但是提交表单却发现赋值并未生效。我画了一个简图，大体上说，Item是一个单向的赋值，会把一个数据丢给Form控件来展现，而Form提交的时候用的是一个叫做Updates的数据副本，并不使用Item。两者通过表单控件的Default值来设置，单向、一次性赋值。

效果即，你希望修改的是表单的提交数据，但是实际上做不到对其赋值操作。那么怎么办呢？文档是不会告诉你的。

目前我做法是，自行编写update、patch进行数据更新。那么问题又来了，这么做就无法使用Form表单上自带的那些方便的功能了啊，比如验证、长度限制、必填等，都没了哦！是的，这就是一个看起来很美，但是实际上并不好用的鸡肋。

不过，不管这个控件算不算鸡肋，多掌握一个知识点总归是有用的，起码避免了自己掉进坑里还不知道嘛！

5.没有事务的数据库操作

事务性对一个正常的业务系统有多重要，做过开发的应该都清楚，我就不赘述了。Canvas app的数据连接，通过一种叫做连接器的机制实现的，从原理上就是一个代理模式。这种模式下，代理不支持事务，Canvas app自然也就没有事务性了。

文档里没有提这个软肋，但是我还是单独拎出来说一下。免得不知内情的同仁真的望文生义把Canvas app当作一个真正意义上的App去用了。一旦用错了东西，应该是项目推进中无可比肩的最大最深最黑的坑吧！

关于Canvas app的坑，先写到这里吧！一次写太多大家也不爱看。

其实Canvas app里的坑还有很多，比如，无法复用代码（有变通的方式但也有副作用）、不支持全局查找啊、调试界面无法刷新到正确的变量啊、表达式使用dispaly name而不是schema name(多语言开发的团队会踩坑)啊！总体来说，这是一个看起来很美，实际上（对程序员）不好用的东西。

不过还是说句公允的一点的话吧，这东西对程序猿不友好的一个原因在于，其设计思路和Excel公式一脉相承。对于程序开发人员来说不便之处，对于精通Excel公式的“表哥”、“表妹”们（文员小哥哥小姐姐）可能并不是太大的困难。

如果用户企图把这个东西当作一个联机增强版的Excel，由那些了解业务的“表哥”、“表妹”们来做一些小应用自己用，她们更容易感受到对工作的增益。毕竟Power Plarform主打的是低代码开发，面向人群本来就是业务用户，而不是专业程序员。而Power apps是Power Plarform中的一部分，Canvas app又是Power apps的一部分（别嫌绕，就这么回事）。低代码啥意思啊，那不就是威力加强版的Excel公式外加App界面和联机数据嘛！

反之，如果把这个东西视作一个真正意义上的App，对其赋予了过高的期待，后果往往会比较惨。除了各种不支持，在计费问题上，很有可能会被吓哭。因为除了Canvas app本体是需要收费的，数据库的连接也是要单独计费的哦！