Web 前端,要不要给文案做变量替换?
2016-05-11 本文已影响200人
表象
通常我们这么做:
<p>恭喜你,发布成功!</p>
<button name="share">立即分享</button>
但有时候,我们会这样做:
<p>{{DONE_TEXT1}}</p>
<button name="share">{{DONE_BUTTON_SHARE}}</button>
好处:
- 统一替换某一文案时,杜绝带来不一致的可能
- 文案集中便于检查错别字;更优雅
- 使多语言化成为可能
好处相当明显,但在这么做之前,你需要了解以下情况:
好处的局限性:
- 由于变量拆分更复杂和需要多角色参与,因此一个项目中实际被复用 2+ 次的文案将 literally 屈指可数
- 前端文案的重复部分很少,且复杂度有限。因此在不太大规模的项目中不一致问题可控。
坏处:
- 大部分情况变量无法正常地命名(因 string 本身没有明确/完整的语义),必然出现很多 text1, text2
A const like STRING_ONE is just a (daily) WTF.
-
用变量代替文案很大影响了 HTML 的可读性,可读性低的代码更易出错
-
与变量拼接的文案(正则替换)使产品经理需要了解并正确使用程序变量,PM 将有可能制造 bug
-
与变量拼接的文案,事实上是一个模板
-
HTML 作为模板本身有语义的,HTML 语义与文案语义不能分割,分别设计有重复之嫌
-
由于带来开发成本,往往会导致削减文案与 HTML/数据更丰富结合的需求
代价:
- 多维护一张文案表
- 风格需要统一,不能存在部分替换部分不替换的情况。以此你会为只有一次使用的文案(这是大部分)做(目的仅仅为风格统一的)大量体力劳动
- 使得前端代码必须编译(否则程序执行效率低且不利于 SEO)
最近讨论的简单总结,欢迎指正。