我想使用新的函数(…)从非常简化的代码生成函数.我想这样做
>避免自己解析表达式
>尽可能灵活.
我尽可能避免使用eval().但是我不确定它是否足够安全以使用新功能(…),这也被称为易受安全漏洞影响.
背景
我想管理菜单按钮的状态.所以,在定义按钮时,我想写一些类似的东西
{
..., // More button definition
state: "isInEditmode && (isWidgetSelected || isCursorInWidget),
...
}
在几个事件期间处理状态转换时,我将检查(汇总)当前整体状态对象的状态与状态属性中的状态.
所以我会在渲染过程中生成一个Function并将其作为DOM对象属性附加,而不是以这种方式附加DOM属性:
...
$el.stateFn = new Function("stateObj", "with (stateObj) {return " + item.state + ";}");
...
测试状态:
visible = $el.stateFn.call(currentStates, currentStates);
with语句帮助我将当前状态对象的属性作为变量提供,以便上面的表达式不需要像obj.isInEditmode那样的东西.
安全问题
在我看来,这不会引入安全漏洞,因为附加到DOM对象的函数是在渲染时生成并从源读取的.还是我错了?我应该避免这个吗?
性能提示受到赞赏(评论)(我认为只要我在渲染时评估一个新的函数,这是可以接受的).
编辑1
>我正在使用Backbone.js.使用另一个框架是不可能的.
>某些菜单项需要绑定到不同甚至多个模型.
>委托(或门面/代理?)模型是相当可观的.
解决方法:
如果允许用户输入在代码中突破,那么安全性也同样糟糕.但是,维护方面,当本地eval与您的示波器混淆并导致动态范围时,您不必担心隐藏的错误.
性能方面,新函数生成的函数与任何其他函数完全相同.生成速度较慢,但在eval中它不会导致包含范围不可优化.
事实上,新功能可用于改善以下情况下的性能:
//Will behave like function a( obj ) { return obj.something }
function makePropReader( propName ) {
return new Function( "obj", "return obj." + propName );
}
构造函数will perform better比这里返回的函数:
function makePropReader( propName ) {
return function( obj ) {
return obj[propName];
}
}
由于必须从闭包上下文动态读取propName,并在每次调用时对对象执行动态读取.