关于组件的 attribute 透传

[errorrik]

san 目前不支持组件的 attribute 透传。

const Button = san.defineComponent({
    template: '<button><slot/></button>'
});

const App = san.defineComponent({
    components: {'b-tn': Button}},
    template: '<b-tn title="hello">ok</b-tn>'
});

// result:
// <button>ok</button>
// 
// result not: 
// <button title="hello">ok</button>

attribute 透传会破坏一定的视图封装性，目前 san 只内建了 id class style 的透传逻辑，其他都不支持。 但是，最近遇到一些场景，属性透传在一些标准明确规定用途的场景，貌似是有用的。如果不支持透传，那所有这些场景，组件在实现的时候很多 attribute 都得在根元素写一遍。所以想拿出来讨论下：

要不要支持组件的 attribute 透传

1. 全部支持
2. 部分支持。data- aria- title alt 等
3. 不支持

如果是部分支持，那是哪部分？

使用时如何声明

使用时如何声明要透传的 attribute？和 data 一样声明的话，san 是不区分属性 prop 的，所以不知道这东西是 data 还是 attribute。还有一种是 title:native="value"。还有没有别的更好的设计

如果组件内根元素有声明的话，怎么处理？

1. 以组件内声明为准
2. 外部传入覆盖内部

[otakustay]

1. DOM有哪些属性是可以枚举的，比如DOM的TS定义里就有一份
2. 问题是，组件的下面一定是原生DOM吗，不是的话透过去会产生不可预计的影响
3. 基于2，我觉得实际的问题是“透传由组件开发者声明，还是使用者声明”

[Justineo]

先明确定义一下，这个“透传”应该是指：把通过静态、插值或 s-bind 传入的属性直接输出到组件根元素上。

对比一下：

• React：没有透传，组件作者需要将 props 自行解构/重组后有选择性地把需要透传的属性 spread 到指定元素上。
• Vue：默认有透传，但是不会包括已经在 props 中定义的属性。可以通过组件选项 inheritAttrs: false 关闭透传，未被定义的属性会被收集到一个 $attrs 对象中（Vue2 的行为，Vue 3 略有差异，但大致类似）。

可以看到，组件作者明确描述“传进来的属性中哪些需要/不需要输出到 DOM”都是必须的。

但是 San 并没有 props 的声明，所以我理解如果全部透传，会导致传入的所有东西都输出到根元素上，这显然是不能接受的。如果不想改变组件内部的设计，那么只能在传入时加入标识。

如果不支持透传，那所有这些场景，组件在实现的时候很多 attribute 都得在根元素写一遍。

如果可以支持把传进来的属性都收集起来，然后用 s-bind 整体输出到根元素，其实也就和 React 复杂度差不多，但需要组件开发者重新认识一下组件开发的范式，外部传入的所有“参数”都需要在内部进行适当的处理。

个人不建议给一个默认透传的“白名单”，因为 1. 增加记忆成本和框架维护负担，2. 如果用户遇到在白名单外的属性，依然会有相应的诉求。

所以我的想法是不默认透传更多属性。

1. 提供新的绑定语法来表达透传，组件使用者负责正确性
2. 组件内提供获取所有绑定的方法，组件开发者保证正确输出

[errorrik]

根据 @Justineo 的观点， @otakustay 的问题3，答案就是 使用者声明，使用者自己负责 咯？我个人觉得是 ok 的。 @otakustay 觉得呢？

如果是这样，新的绑定语法 要设计成什么样？在 san 目前的模板语法下，我能想到的就是 title:native="value"，通过 :native 标识

另外，我觉得组件选项 inheritAttrs: false 关闭透传，应该也是需要支持的。这是组件开发者应该有的权力

[Justineo]

我本来想的是二选一，你外面只管传，全交给组件作者去处理也是可以的。这个会更安全一些，给组件作者更多职责，优先级、merge 问题也可以组件作者来解决。

我看到 San 现在有个 autoFillStyleAndId 开关，可能还要考虑下新的属性和这个开关的关系。

[errorrik]

你外面只管传，全交给组件作者去处理也是可以的。这个会更安全一些，给组件作者更多职责，优先级、merge 问题也可以组件作者来解决

组件作者咋处理来着，没太理解

[otakustay]

使用者声明，使用者负责事实上就是一种抽象泄露吧。使用者必须知道组件提供者的内部实现（比如渲染对应的是DOM元素还是另一个组件）才能确定要不要透传，同时组件提供者把内部实现改了（<button>改成了<my-fancy-button>）又会导致使用者的决定失效，而这种修改不会发大版本……

[Justineo]

组件作者咋处理来着，没太理解

内部能获取到所有绑定的值，自行选择性输出到 DOM 上。

[errorrik]

内部能获取到所有绑定的值，自行选择性输出到 DOM 上

这不就是不透传么。现在本来就能获取呀

[otakustay]

这不就是不透传么。现在本来就能获取呀

区别是组件开发者要手动写一下“传”还是“不传”，开发者说不传，使用都传了也没用

[errorrik]

使用者声明，使用者负责事实上就是一种抽象泄露吧。使用者必须知道组件提供者的内部实现（比如渲染对应的是DOM元素还是另一个组件）才能确定要不要透传，同时组件提供者把内部实现改了（改成了）又会导致使用者的决定失效，而这种修改不会发大版本……

这就是讨论这个问题的原因呀。会造成一定程度的视图封装性，但是这场景又不少

[errorrik]

区别是组件开发者要手动写一下“传”还是“不传”，开发者说不传，使用都传了也没用

那默认是啥呢，嘿嘿

[Justineo]

我理解自动透传的场景就是组件作者已经没处理了，但是有些场景又特别想要强制输出一下。这个其实和魔改组件样式类似。

[errorrik]

我理解自动透传的场景就是组件作者已经没处理了，但是有些场景又特别想要强制输出一下。这个其实和魔改组件样式类似。

vue 就是自动透传的，有遇到什么 bad practices 么

[otakustay]

那默认是啥呢，嘿嘿

按道理现在的默认只能是“不传”，不然就是BREAKING CHANGE……

如果让使用者选择强制透传，那我们得考虑这么些事：

1. 使用者要知道组件内部结构才能判断传不传吗？
2. 当使用者说“透”的时候，透一层还是透N层直到DOM节点？
3. 要不要增加机制让使用都加个断言，比如（底下是DOM时传，不是时给我warning）

[errorrik]

按道理现在的默认只能是“不传”，不然就是BREAKING CHANGE……

也不是。增加新的声明语法，就不算是 breaking change

[errorrik]

当使用者说“透”的时候，透一层还是透N层直到DOM节点？

我试了下，vue 是透 n 层

[otakustay]

我试了下，vue 是透 n 层

如果使用者的思路是“我知道这玩意最后是个div，我要div上有title”，那肯定是要透N层一直到DOM为止的。我也很难想象使用者只希望透1层的情况

[otakustay]

如果使用者的思路是“我知道这玩意最后是个div，我要div上有title”，那肯定是要透N层一直到DOM为止的。我也很难想象使用者只希望透1层的情况

但依然要支持中间把透传这个事中断掉，比如有一个组件它的title有特殊用处（比如变成tooltip），那么这个title它应该“吞掉”？

[errorrik]

但依然要支持中间把透传这个事中断掉，比如有一个组件它的title有特殊用处（比如变成tooltip），那么这个title它应该“吞掉”？

这就是我上面说的，如果组件内根元素有声明的话，怎么处理？

• 以组件内声明为准
• 外部传入覆盖内部

[errorrik]

使用者要知道组件内部结构才能判断传不传吗？ 如果使用者的思路是“我知道这玩意最后是个div，我要div上有title”，那肯定是要透N层一直到DOM为止的。我也很难想象使用者只希望透1层的情况

我感觉，透传这件事，使用者的认知应该是：我知道这玩意最终是个 HTMLElement，我想给它加 attribute。 所以，不能算是感知组件内部结构。 另外，如果最终组件不是个 HTMLElement（比如没有一个 root element），那直接失效就好了

[otakustay]

有个歪门邪道的想法，透传弄个特殊的prop呢，比如$attr={title: '', 'aria-label': 'Close'}

当然这个要很谨慎，加了个玩意以后可不好撤回来

[errorrik]

有个歪门邪道的想法，透传弄个特殊的prop呢，比如$attr={title: '', 'aria-label': 'Close'}

当然这个要很谨慎，加了个玩意以后可不好撤回来

那还不如挨个声明呢 title:attr=""，毕竟 attribute 其实是 string

[errorrik]

整了个便于表达观点的 comment 和 list， @otakustay @Justineo 看看

1. 一些框架的现状

• react：完全没有透传。组件作者需要将 props 自行解构/重组后有选择性地把需要透传的 attr spread 到指定元素上
• vue：
  • 有 props 和 emits 声明暴露的可传入属性和触发事件
  • 默认有透传，exclude 掉 props 中定义的属性
  • 透传可以关闭，通过组件选项 inheritAttrs: false
  • 通过 $attr 可以在组件内任意结构的部分，来自定义透传到哪个内部的 element
  • vue2 中支持 v-on:focus.native 来绑定 native event。vue3 取消了这个支持，事件会默认透传，exclude 掉 emits 中定义的属性
• san：
  • 没有 prop 的概念，所有模板声明的 attr 都会当成 data 绑定
  • 默认透传 id / class / style。其他 attr 没有透传，组件作者自己使用绑定传入的数据，在指定元素上写 attr
  • 默认透传可以关闭，通过组件选项 autoFillStyleAndId: false
  • 支持 on-click="native:clicker(title)" 来绑定 native event

2. san 要怎么做

在一些场景下，属性透传在一些标准明确规定用途的场景，貌似是有用的。如果不支持透传，那所有这些场景，组件在实现的时候很多 attribute 都得在根元素写一遍。 再结合上面一些框架的现状，我们需要考虑 san 要不要做，要怎么做。下面是一些细化的问题

2.1 支持透传

san 要不要支持透传 id / class / style 之外更多的 attribute

• A 支持
• B 不支持

如果 2.1 选不支持，就不用往后看了。

2.2 默认支持透传

san 支持透传的行为，默认是支持透传还是关闭透传？

• A 默认支持透传
• B 默认关闭透传

2.3 控制透传行为的选项

无论默认行为是什么，肯定需要支持选项来控制透传的行为，比如让组件开发者能够关闭透传

• A {boolean}inheritAttrs 直接打开或关闭
• B {boolean|Array}inheritAttrs string 数组，支持 *。默认值是 ['id', 'class', 'style']
• C 其他命名或其他控制功能的选项（请说明下）

2.4 透传的组件层级

• A 一层
• B 多层

2.5 属性冲突的行为

假设外部声明了 title 透传，但是组件内的根元素也声明了 title attribute，如何处理

• A 以内部为准
• B 以外部为准
• C 增加选项控制（请说明下）

2.6 支持组件开发者定制属性透传行为

如果要支持组件开发者定制属性透传行为，需要让组件开发者能够拿到外面传入的预期透传的东西。然后就可以随便玩了

• A 不支持
• B 通过特殊的 data 项。this.data.get('$attrs')
• C 其他方式（请说明下）

2.7 透传 attribute 的声明语法

• A attr-title="title"。目前声明的语法还没有在 attribute name 上做文章的语法，和之前的设计保持一致。缺点是不能有 data 叫做 attrTitle
• B attr:title="title"。
• C title="title"。由于没有 prop 的概念，所以如果在声明语法上不做区分，那组件需要支持声明哪些属于透传 attr，2.3 需要选 B。这也有一个缺点，透传 attr 和 data 不能重合

[otakustay]

首先，肯定有支持。但我有2套方案：

1. 由组件开发者决定能不能透传，默认关闭，使用inheritAttrs打开，打开后就全透，透N层，使用者直接写style、title这样，没任何特殊性，与组件自身的data冲突的情况下，中间吞掉
2. 由组件开发者决定要不要透传，默认开启，没有类似inheritAttrs的标记，所有透传的属性用attr:title或者找个前缀如^title来传，透N层，不存在冲突也不存在开发者定制

从前面讨论来看，我认为我们需要的是方案2

[errorrik]

由组件开发者决定要不要透传

这句话没理解 @otakustay

[otakustay]

开发者写了inheritsAttr: true，使用者写title="abc"就会去DOM上

开发者不写inheritsAttr: true，使用者怎么写都没有透传效果

[otakustay]

2. 由组件开发者决定要不要透传，默认开启

这里应该是使用者决定，写错了

[errorrik]

我个人倾向是：

2.1 支持透传

san 要不要支持透传 id / class / style 之外更多的 attribute

• A 支持
• B 不支持

A

2.2 默认支持透传

san 支持透传的行为，默认是支持透传还是关闭透传？

• A 默认支持透传
• B 默认关闭透传

A

2.3 控制透传行为的选项

无论默认行为是什么，肯定需要支持选项来控制透传的行为，比如让组件开发者能够关闭透传

• A {boolean}inheritAttrs 直接打开或关闭
• B {boolean|Array}inheritAttrs string 数组，支持 *。默认值是 ['id', 'class', 'style']
• C 其他命名或其他控制功能的选项（请说明下）

A

2.4 透传的组件层级

• A 一层
• B 多层

B

2.5 属性冲突的行为

假设外部声明了 title 透传，但是组件内的根元素也声明了 title attribute，如何处理

• A 以内部为准
• B 以外部为准
• C 增加选项控制（请说明下）

A 要加控制选项以后再说，要加到时候也默认 A

2.6 支持组件开发者定制属性透传行为

如果要支持组件开发者定制属性透传行为，需要让组件开发者能够拿到外面传入的预期透传的东西。然后就可以随便玩了

• A 不支持
• B 通过特殊的 data 项。this.data.get('$attrs')
• C 其他方式（请说明下）

B 或者 C 因为 2.7 我选 A 了，自然能够通过 this.data.get('attrTitle') 拿到

2.7 透传 attribute 的声明语法

• A attr-title="title"。目前声明的语法还没有在 attribute name 上做文章的语法，和之前的设计保持一致。缺点是不能有 data 叫做 attrTitle
• B attr:title="title"。
• C title="title"。由于没有 prop 的概念，所以如果在声明语法上不做区分，那组件需要支持声明哪些属于透传 attr，2.3 需要选 B。这也有一个缺点，透传 attr 和 data 不能重合

A html attr name valid B 太丑了

[otakustay]

2.1 支持透传

san 要不要支持透传 id / class / style 之外更多的 attribute

• A 支持
• B 不支持

如果 2.1 选不支持，就不用往后看了。

A：支持

2.2 默认支持透传

san 支持透传的行为，默认是支持透传还是关闭透传？

• A 默认支持透传
• B 默认关闭透传

A：默认开

2.3 控制透传行为的选项

无论默认行为是什么，肯定需要支持选项来控制透传的行为，比如让组件开发者能够关闭透传

• A {boolean}inheritAttrs 直接打开或关闭
• B {boolean|Array}inheritAttrs string 数组，支持 *。默认值是 ['id', 'class', 'style']
• C 其他命名或其他控制功能的选项（请说明下）

A：用inheritsAttr: boolean

2.4 透传的组件层级

• A 一层
• B 多层

B：多层

2.5 属性冲突的行为

假设外部声明了 title 透传，但是组件内的根元素也声明了 title attribute，如何处理

• A 以内部为准
• B 以外部为准
• C 增加选项控制（请说明下）

A：以内部为准，不然要是后面有些逻辑依赖DOM attr值就完蛋了

2.6 支持组件开发者定制属性透传行为

如果要支持组件开发者定制属性透传行为，需要让组件开发者能够拿到外面传入的预期透传的东西。然后就可以随便玩了

• A 不支持
• B 通过特殊的 data 项。this.data.get('$attrs')
• C 其他方式（请说明下）

A：不支持

2.7 透传 attribute 的声明语法

• A attr-title="title"。目前声明的语法还没有在 attribute name 上做文章的语法，和之前的设计保持一致。缺点是不能有 data 叫做 attrTitle
• B attr:title="title"。
• C title="title"。由于没有 prop 的概念，所以如果在声明语法上不做区分，那组件需要支持声明哪些属于透传 attr，2.3 需要选 B。这也有一个缺点，透传 attr 和 data 不能重合

B：或者写^title

[Justineo]

2.1 支持透传

san 要不要支持透传 id / class / style 之外更多的 attribute

• A 支持
• B 不支持

A

如果 2.1 选不支持，就不用往后看了。

2.2 默认支持透传

san 支持透传的行为，默认是支持透传还是关闭透传？

• A 默认支持透传
• B 默认关闭透传

A

2.3 控制透传行为的选项

无论默认行为是什么，肯定需要支持选项来控制透传的行为，比如让组件开发者能够关闭透传

• A {boolean}inheritAttrs 直接打开或关闭
• B {boolean|Array}inheritAttrs string 数组，支持 *。默认值是 ['id', 'class', 'style']
• C 其他命名或其他控制功能的选项（请说明下）

A（命名可以按 San 目前的习惯调整）

2.4 透传的组件层级

• A 一层
• B 多层

B（用户本身也不应该知道里面有几层，预期就是往 DOM 上写，那么一层肯定不合理）

2.5 属性冲突的行为

假设外部声明了 title 透传，但是组件内的根元素也声明了 title attribute，如何处理

• A 以内部为准
• B 以外部为准
• C 增加选项控制（请说明下）

这个我没太想好，Vue 是外部为准的，似乎也没遇到太多问题，因为组件内部逻辑依赖的 DOM 属性一般都不太会是通用的属性。如果要为了安全的话可以以内部为准然后外部设置的时候提供 override 的机制。

2.6 支持组件开发者定制属性透传行为

如果要支持组件开发者定制属性透传行为，需要让组件开发者能够拿到外面传入的预期透传的东西。然后就可以随便玩了

• A 不支持
• B 通过特殊的 data 项。this.data.get('$attrs')
• C 其他方式（请说明下）

B（inheritAttrs 关闭时，这个应该是必须的，否则组件开发者没法自定义透传行为了）

2.7 透传 attribute 的声明语法

• A attr-title="title"。目前声明的语法还没有在 attribute name 上做文章的语法，和之前的设计保持一致。缺点是不能有 data 叫做 attrTitle
• B attr:title="title"。
• C title="title"。由于没有 prop 的概念，所以如果在声明语法上不做区分，那组件需要支持声明哪些属于透传 attr，2.3 需要选 B。这也有一个缺点，透传 attr 和 data 不能重合

反正不能是 A, C。

Vue 有一个语法表示绑定的时候 强制用 setAttribute：title.attr，缩写 ^title，但是语义和这里不太一样。

^title 这样比较短写起来比较舒服，但是的确 San 属性名没有特殊语法，需要斟酌一下。

[100pah]

2.1 支持透传 san 要不要支持透传 id / class / style 之外更多的 attribute

A 支持 B 不支持

• 选 A

2.2 默认支持透传 san 支持透传的行为，默认是支持透传还是关闭透传？

A 默认支持透传 B 默认关闭透传

• 选 A （前提是不产生 breaking change ，参见 2.7）

2.3 控制透传行为的选项 无论默认行为是什么，肯定需要支持选项来控制透传的行为，比如让组件开发者能够关闭透传

A {boolean}inheritAttrs 直接打开或关闭 B {boolean|Array}inheritAttrs string 数组，支持 *。默认值是 ['id', 'class', 'style'] C 其他命名或其他控制功能的选项（请说明下）

• 不选B ，因为，此时我理解，这个功能本质是个“妥协”，如果开发者能考虑到以及考虑完善 “哪些属性应该支持设置到 DOM 上”，那么是否也不需要本功能了？假如开发者想要定义能设置 aria ，那么用此处提供的 ”透传设定“ 来设置 aria 是否不是最佳实践？如果这个理解有道理，那么如果选 B ，开发者怎么使用，都不合适的。
• 选 A （A 的意思改为，'id', 'class', 'style' 无论如何都透传，inheritAttrs=false 只能控制其他属性不透传，命名或枚举值可适当调整。可能很少有”组件开发者“会使用这个选项，除非遇到不可调和的问题？）。

2.4 透传的组件层级 A 一层 B 多层

• 选 B

2.5 属性冲突的行为 假设外部声明了 title 透传，但是组件内的根元素也声明了 title attribute，如何处理

A 以内部为准 B 以外部为准 C 增加选项控制（请说明下）

• 选择和现在 'id', 'class', 'style' 一样的方式。（暂不确定 'id', 'class', 'style' 是以内部为准还是外部）。如果和 'id', 'class', 'style' 不一样，会可能让开发者难于理解？

2.6 支持组件开发者定制属性透传行为 如果要支持组件开发者定制属性透传行为，需要让组件开发者能够拿到外面传入的预期透传的东西。然后就可以随便玩了

A 不支持 B 通过特殊的 data 项。this.data.get('$attrs') C 其他方式（请说明下）

• 不选 B 和 C，因为：
  • 基本原因参见 2.3
  • 特殊 data 项是否为 breaking change ，且这种特殊设定不易被注意到或查询到。
• 选 A

2.7 透传 attribute 的声明语法 A attr-title="title"。目前声明的语法还没有在 attribute name 上做文章的语法，和之前的设计保持一致。缺点是不能有 data 叫做 attrTitle B attr:title="title"。 C title="title"。由于没有 prop 的概念，所以如果在声明语法上不做区分，那组件需要支持声明哪些属于透传 attr，2.3 需要选 B。这也有一个缺点，透传 attr 和 data 不能重合

• 不选 A ，因为，感觉 attr-title 从字面上看不易知道有特殊行为，且不易被查询到。
• 不选 C ，原因如题述。
• 选 B ，因为，从字面上看是有特殊行为的。

[errorrik]

^title 这样比较短写起来比较舒服，但是的确 San 属性名没有特殊语法，需要斟酌一下

attr:title san 现在也没有。 @Justineo 为啥不能是 attr-title。san 里现在就是 s- on- ，以前有个 prop- 后来干掉了。 确实可能有冲突，但是，我又想了下，如果谁现在设计的组件里的 data 有叫做 attrXxx 的项，我会觉得这挺诡异的

[errorrik]

选择和现在 'id', 'class', 'style' 一样的方式。（暂不确定 'id', 'class', 'style' 是以内部为准还是外部）。如果和 'id', 'class', 'style' 不一样，会可能让开发者难于理解？

@100pah 这个肯定不一样的。class 和 style 是会内外 merge 的

[errorrik]

我其实很纠结 attr-title= 还是 attr:title=

之前 modifier 的设计，就尽量避免了设计 invalid html attribute name，所以是 on-click="capture:native:func()"

所以，目前，标签绑定声明属性是只有 xx- 语法的

[errorrik]

@100pah 在 san 过往的惯例里，把 minor 版本当成大版本，是可以有合理的 breaking change 的。可以看看 https://github.com/baidu/san/blob/master/CHANGELOG.md

当然，主要搞的是严格意义算 breaking change，但是实际并不会有明显影响的。广泛的影响还是不能搞

[100pah]

这个肯定不一样的。class 和 style 是会内外 merge 的

哦是。

在 san 过往的惯例里，把 minor 版本当成大版本，是可以有合理的 breaking change 的。可以看看 https://github.com/baidu/san/blob/master/CHANGELOG.md

嗯嗯，觉得是“测试修改成本”和“收益”的权衡。

为啥不能是 attr-title。san 里现在就是 s- on- ，以前有个 prop- 后来干掉了。 确实可能有冲突，但是，我又想了下，如果谁现在设计的组件里的 data 有叫做 attrXxx 的项，我会觉得这挺诡异的

这想到，有见过 “把所有属性值系统性的进行某种转换后，属性名加上双下划线放在 data 里” 的代码，非业务代码而是基于 san 的封装的框架代码。但不知这是否能推演出 ”对于 attr 这个词也会有超出想象的使用“。

另外看到 on-click 想到，attr 这个词是否含义太泛了，没有表达出相对更准确的意图。

[errorrik]

另外看到 on-click 想到，attr 这个词是否含义太泛了，没有表达出相对更准确的意图。

attr 一般还是指 element 的 attribute。组件的概念大家都认知是 prop ｜data，以及 state 之类

这想到，有见过 “把所有属性值系统性的进行某种转换后，属性名加上双下划线放在 data 里” 的代码，非业务代码而是基于 san 的封装的框架代码。但不知这是否能推演出 ”对于 attr 这个词也会有超出想象的使用“。

我想象不出来。另外，既然是非业务代码，那自身就是中间层，对外不暴露的，就算冲突了，也会有严格的版本控制，我理解影响还好。

这里的设计，我主要的考虑，还是和过往语法的一致性。使用者认知成本问题

[errorrik]

看起来 2.1 - 2.5 都非常一致了。2.6 和 2.7 在之前的讨论中还有点分歧 我把观点整理收集下，选项也收敛下，再来一遍。这是最后一次，最终方案以投票为准

2.6 支持组件开发者定制属性透传行为

没有人选 C

如果要支持组件开发者定制属性透传行为，需要让组件开发者能够拿到外面传入的预期透传的东西。然后就可以随便玩了 有一种观点是暂时没想到场景，可以选择先不支持。一种典型的场景是，组件开发者想把透传的 attribute 不要放在实际的 root el 上，而是放在内部的某个 el 上，因为 root el 可能仅仅是布局用或样式用的无意义 el。 还有一种观点是，在 data 上增加特定的项，属于特殊设定，可能不易理解或有冲突。但是 san 的设计里视图是 data 的直接映射，如果要支持，也只能在 data 上做文章。否则也只能选择不支持了。

所以，选项剩下：

• A 不支持
• B 通过特殊的 data 项。this.data.get('$attrs')

2.7 透传 attribute 的声明语法

没有人选 C。选 B 的比较多，直接的感觉是 B 比较顺眼。 但这里有两个点，是和 san 现在的设计相关的，所以这两个点再拿出来给大家看看。

1. 目前所有的绑定语法，在 attr name 部分都是 xx-，有 s- on- var- prop-。还没有其他 pattern
2. 事件声明的 modifier，是在 value 里做文章的，on-click="capture:handle()" on-click="native:handle()"。来个 attr:name 感觉有点割裂

看基于这两个信息，大家遵循内心会是怎么设计和选择。所以，选项剩下：

• A attr-title="title"。目前声明的语法还没有在 attribute name 上做文章的语法，和之前的设计保持一致。缺点是不能有 data 叫做 attrTitle
• B attr:title="title"。

[100pah]

2.6 支持组件开发者定制属性透传行为 没有人选 C

如果要支持组件开发者定制属性透传行为，需要让组件开发者能够拿到外面传入的预期透传的东西。然后就可以随便玩了 有一种观点是暂时没想到场景，可以选择先不支持。一种典型的场景是，组件开发者想把透传的 attribute 不要放在实际的 root el 上，而是放在内部的某个 el 上，因为 root el 可能仅仅是布局用或样式用的无意义 el。 还有一种观点是，在 data 上增加特定的项，属于特殊设定，可能不易理解或有冲突。但是 san 的设计里视图是 data 的直接映射，如果要支持，也只能在 data 上做文章。否则也只能选择不支持了。

所以，选项剩下：

A 不支持 B 通过特殊的 data 项。this.data.get('$attrs')

• 选 A

• 不选 B （除非 this.data.get('$attrs') 能承担更重要的意义。仅为现在这个场景而言，加这种特殊设定觉得有点重了）

• Update: 交流后得知 element-ui 、veui 等组件库里，确实有不少 $attrs 的写法。所以实现 B 也是可以的。并在文档中给 “组件开发者” 以推荐的做法。

2.7 透传 attribute 的声明语法 没有人选 C。选 B 的比较多，直接的感觉是 B 比较顺眼。 但这里有两个点，是和 san 现在的设计相关的，所以这两个点再拿出来给大家看看。

目前所有的绑定语法，在 attr name 部分都是 xx-，有 s- on- var- prop-。还没有其他 pattern 事件声明的 modifier，是在 value 里做文章的，on-click="capture:handle()" on-click="native:handle()"。来个 attr:name 感觉有点割裂 看基于这两个信息，大家遵循内心会是怎么设计和选择。所以，选项剩下：

A attr-title="title"。目前声明的语法还没有在 attribute name 上做文章的语法，和之前的设计保持一致。缺点是不能有 data 叫做 attrTitle B attr:title="title"。

• 稍倾向于选 B

• 如果选 A 的话，可行为是：<some attr-title="xxx"/> 得到效果：

  • 同时 data.get('attrTitle'); 能得到 'xxx'
  • 且 <div title="xxx">
  • （这样即便现在有人使用了属性叫做 attrTitle ，也影响有限，只是 div 上多加了些东西）

• Update：思考过后，觉得均可，没有倾向性。

[errorrik]

2.6 支持组件开发者定制属性透传行为 没有人选 C

如果要支持组件开发者定制属性透传行为，需要让组件开发者能够拿到外面传入的预期透传的东西。然后就可以随便玩了 有一种观点是暂时没想到场景，可以选择先不支持。一种典型的场景是，组件开发者想把透传的 attribute 不要放在实际的 root el 上，而是放在内部的某个 el 上，因为 root el 可能仅仅是布局用或样式用的无意义 el。 还有一种观点是，在 data 上增加特定的项，属于特殊设定，可能不易理解或有冲突。但是 san 的设计里视图是 data 的直接映射，如果要支持，也只能在 data 上做文章。否则也只能选择不支持了。

所以，选项剩下：

A 不支持 B 通过特殊的 data 项。this.data.get('$attrs')

B 从 vue 的各个组件库来看，这种需求还不少

2.7 透传 attribute 的声明语法 没有人选 C。选 B 的比较多，直接的感觉是 B 比较顺眼。 但这里有两个点，是和 san 现在的设计相关的，所以这两个点再拿出来给大家看看。

目前所有的绑定语法，在 attr name 部分都是 xx-，有 s- on- var- prop-。还没有其他 pattern 事件声明的 modifier，是在 value 里做文章的，on-click="capture:handle()" on-click="native:handle()"。来个 attr:name 感觉有点割裂 看基于这两个信息，大家遵循内心会是怎么设计和选择。所以，选项剩下：

A attr-title="title"。目前声明的语法还没有在 attribute name 上做文章的语法，和之前的设计保持一致。缺点是不能有 data 叫做 attrTitle B attr:title="title"。

A var- 也是实现 scoped slot 的时候后加的。 其实都可以。个人语法干净一致性强迫症

[otakustay]

2.6 支持组件开发者定制属性透传行为

A 不支持，有需求可以再讨论，但当前即便支持this.data.get('$attr')，拿到后又怎么放到某个DOM上去呢，现在有展开对象到DOM上的这种操作符吗？

2.7 透传 attribute 的声明语法

A 但讨论下是用attr-*还是s-attr-*？

[errorrik]

但当前即便支持this.data.get('$attr')，拿到后又怎么放到某个DOM上去呢，现在有展开对象到DOM上的这种操作符吗？

<div>
  <input s-bind="$attrs" />
</div>

[errorrik]

但讨论下是用attr-还是s-attr-

目前 s- 留给内部指令。 s-for s-if s-elif s-else s-bind s-html s-transition s-is s-show，暂时没有动态的

见这里 https://github.com/baidu/san/blob/master/src/parser/parse-directive.js

[Justineo]

2.6：支持。为了能让用户快速在模板里面 spread，需要能在 this.data.get() 中获取，所以这里就是起一个特殊的名字来避开用户命名的 data/prop。$attrs 在 Vue 行得通是因为 Vue 有“内部属性以 $ 开头直接挂在 this 上“的约定，且用户自定义的 prop 如果以 $ 开头是不会被代理到 this 上的。San 加特殊属性是不是可以先做一下用户调研，有没有用 $ 开头设计自己的 data/prop 的情况。

2.7：按 San 目前的语法设计（on- / var-），的确应该使用 attr- 前缀。主要要考虑的也是 breaking change 的情况。

[errorrik]

San 加特殊属性是不是可以先做一下用户调研，有没有用 $ 开头设计自己的 data/prop 的情况。

好，调研一下

[errorrik]

调研完了，未见冲突