自从我阅读React 0.14的发行说明(以及其他相关宣传)以来,这个问题一直在我的脑海中循环 - 我是React的忠实粉丝,我认为无状态组件(https://facebook.github. io/react/blog/2015/09/10/react-v0.14-rc1.html#stateless-function-components)是一个很好的想法,既方便编写这些组件,也用于在代码中表达这些组件的意图对于相同的道具数据,组件应该是一致的"纯粹".
现在的问题是:怎么会有可能发生反应,优化这些无国籍组件功能没有去整猪,并假设道具引用不仅是一成不变的,他们不应该在组件中进行操作,但也他们永远无法改变组件生命周期之外？之所以说"正规"的组件(也就是状态的组件-换句话说,通过整个生命周期中去的部件; componentWillMount,getInitialState,等..)有一个可选的"shouldComponentUpdate"功能是作出反应并不能假定所有的道具和状态引用完全不可变.在渲染组件之后,道具引用的某些属性可能会发生变化,因此相同的"道具"实例可能会在以后具有不同的内容.这就是为什么对使用完全不可变结构感到非常兴奋的原因以及为什么使用Om和React可以提供很好的性能提升; 因为那里使用的不可变结构保证任何对象的任何给定实例都不会被变异,所以shouldComponentUpdate可以对道具和状态执行非常便宜的引用相等性检查(http://swannodette.github.io/2013/12/17/the -future-of-javascript-mvcs /).
我一直试图找到更多有关这方面的信息,但没有任何地方.我无法想象可以在无状态组件周围进行哪些性能改进而不假设道具数据将由不可变类型组成.也许是对非不可变道具类型的一些初步分析,试图猜测"props"和"nextProps"是否代表相同的数据？
我只是想知道是否有人有任何内幕消息或其他一些有启发性的见解.如果React 确实开始要求道具类型"完全不可变"(允许引用相等比较以确认数据没有改变)那么我认为这将是一个很大的进步,但它也可能是一个很大的变化.
我即将开始一个用VBScript编写的遗留系统的迁移项目.它有一个有趣的结构,因为大部分内容是通过将各种组件编写为"WSC"文件来隔离的,这些文件实际上是以类似COM的方式公开VBScript代码的一种方式.从"核心"到这些组件的边界接口是相当紧凑和众所周知的,所以我希望我能够解决编写新核心并重用WSC,推迟他们的重写.
可以通过添加对"Microsoft.VisualBasic"的引用并调用来加载WSC
var component = (dynamic)Microsoft.VisualBasic.Interaction.GetObject("script:" + controlFilename, null);
其中"controlFilename"是完整的文件路径.GetObject返回类型为"System .__ ComObject"的引用,但可以使用.net的"动态"类型访问属性和方法.
这似乎最初工作正常,但我遇到了很多特定情况的问题 - 我担心这可能发生在其他情况下,或者更糟糕的是,坏事情在很多时候都会发生并被掩盖,等到我最不期望的时候爆炸.
引发的异常是"System.ExecutionEngineException"类型,这听起来特别可怕(和模糊)!
我拼凑了我认为最小的重现案例,并希望有人可以对这个问题提出一些看法.我还发现了一些似乎可以阻止它的调整,但我无法解释原因.
创建一个名为"WSCErrorExample"的新的空"ASP.NET Web应用程序"(我在VS 2013/.net 4.5和VS 2010/.net 4.0中完成了这个,它没有区别)
在项目中添加对"Microsoft.VisualBasic"的引用
添加一个名为"Default.aspx"的新"Web窗体",并将以下内容粘贴到"Default.aspx.cs"的顶部
using System;
using System.IO;
using System.Reflection;
using System.Runtime.InteropServices;
using Microsoft.VisualBasic;
namespace WSCErrorExample
{
public partial class Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
var currentFolder = GetCurrentDirectory();
var logFile = new FileInfo(Path.Combine(currentFolder, "Log.txt"));
Action<string> logger = message =>
{
// The try..catch is to avoid IO exceptions when reproducing by requesting …