scale按view划分作key的分隔符是否应该划定一个特殊字符串

[KedAyAyA]

G2/src/chart/util/scale-pool.ts

Line 163 in c625676

const field = last(key.split('-'));

按简单按 '-' 来区分，是否会跟业务场景命名冲突呢，比如color('a-b'), 这种case拿到的不和预期？

[hustcc]

G2/src/chart/util/scale-pool.ts

Line 163 in c625676

const field = last(key.split('-'));

按简单按 '-' 来区分，是否会跟业务场景命名冲突呢，比如color('a-b'), 这种case拿到的不和预期？

Scale key 是按照 view 冒泡上去，然后拼接 view id 和 field。
理论上使用 getScale 方法去拿 scale，现在你的使用场景是啥？

[KedAyAyA]

G2/src/chart/util/scale-pool.ts

Line 163 in c625676

const field = last(key.split('-'));

按简单按 '-' 来区分，是否会跟业务场景命名冲突呢，比如color('a-b'), 这种case拿到的不和预期？

Scale key 是按照 view 冒泡上去，然后拼接 view id 和 field。
理论上使用 getScale 方法去拿 scale，现在你的使用场景是啥？

暂时没有场景遇到，只是看源码的时候发现scale会以view-[field]这种形式，然后这里又split有个获取field的代码，考虑到field是用户的输入，可能有的field是 携带'-'字符的，感觉可能在某些case下跑出问题？

[hustcc]

不会有问题，这么做其实主要就是为了生成 scale 的 id。策略就是 view 冒泡，拼接所有的 view id，最后加上 field 字段名。

然后在做 scale sync 的时候，就可以通过 id 去做 scale 高性能的同步。这个 id 目前来说不会去结构出来使用，所以一般不会出现问题。如果真的正好 field2 = view id + field1 ，确实也可能出现问题，但是这概率也太低了，似乎也很难避免！

[KedAyAyA]

如果真的正好 field2 = view id + field1 ，确实也可能出现问题，但是这概率也太低了，似乎也很难避免！

这种确实是个概率极低的case，我其实想到的是另一种case，field2 = view[id] + field1，此时field1 = 'province-city'，field2 = 'view1-province-city' ,接下来split后取last的时候，就只能拿到 'city'，还原后的field1 = 'city'，感觉不合预期？好像field里可能带 '-' 的概率也不小

[hustcc]

为什么会有 split 后取 last 的操作，现在 G2 代码中没有这个逻辑吧！

[KedAyAyA]

为什么会有 split 后取 last 的操作，现在 G2 代码中没有这个逻辑吧！

这里吖

[hustcc]

确实有问题！

[hustcc]

这个问题先忽略掉了，在 G2 5.0 中避免了这类字符串的分割和解析。