<head> ... <!-- option 1 --> <meta property="app:user_data" content='{"email":"john@gmail.com","id":9283}'> <!-- option 2 --> <meta property="app:user_data:email" content="john@gmail.com"> <meta property="app:user_data:id" content="9283">
命名空间
rsjs建议使用尽可能少的全局变量。共用的类，函数，放到单个Object里，比如叫App：
if (!window.App) window.App = {}; App.Editor = function() { // ... };
在多个行为之间可复用的帮助方法，可以单独建立Object，并将它们分文件保存在helpers/：
/* helpers/format_error.js */ if (!window.Helpers) window.Helpers = {}; Helpers.formatError = function (err) { return "" + err.project_id + " error: " + err.message; };
第三方库的处理
rsjs建议如果引入第三方库，也做成组件行为的形式。比如，Select2的功能，可以只影响带有属性data-js-select2的元素。
// select2.js -- affects `[data-js-select2]` $(function () { $("[data-js-select2]").select2(); });
所有第三方库的代码可以集中到一个类似vendor.js的文件，并和站点本身的代码各自独立。这样，当站点更新代码的时候，用户可以直接利用缓存，而并不需要再次获取这些第三方库代码。
rsjs对自己的归纳
rsjs认为自身的内容更偏向于对开发者友好，也就是更易于维护，而在性能上（对用户友好）可能没有做到最好。以上提到的各项建议，也是有利有弊，rsjs只是在权衡了利弊的基础上得到的更利于长期维护的结论。
rsjs不是万金油，它不适用于单页应用（SPA）等前端功能很复杂的情况。它关注的是的那种多个网页，每个网页一点JavaScript交互的传统网站。
结语
rscss和rsjs所用的“合理”是一个很取巧的表述，不是完美，不是最好，也不是出色，它只是在说希望代码能“合乎道理”。rscss和rsjs大概就是这样，以简约的风格，不长的篇幅，追求着“小而合理”。
目前rsjs还在更新中（work-in-progress），rscss则已经比较成熟。很推荐试试其中你也认为合理的建议！
您可能感兴趣的文章: