remux的一些调整

在上一篇文章中我描述了一个更强大的JavaScript全栈框架。好吧，我承认他在设计有很多失误，当然，为了避免以后再发生这样的事情我决定还是要先做足充分的调研和实践再开始进行设计，总之就放在那提醒自己了。在本文中，我会纠正之前的错误（主要是实现非常困难以及没有必要的部分），并重新规划设计remux框架。

关于远程变量

最主要的一点是，Proxy无法拦截对对象本身的操作，由于我没有详细地查看文档，也没有自己动手实践，一拍脑袋搞出来这么个玩意。

回过头重新想了一下发现其实”远程变量“并没有那么有用，具体来说，一个允许其他端任意修改的空间本就不太有用，还是应该封装成函数来处理，所以干脆就老老实实用RPC函数好了，别整什么远程变量。

关于框架集成

2022年，在后前端工程化时代，已经很少有单纯用一个脚本文件来糊页面了，需要考虑对React & Vue 等库/框架的兼容性，一个页面一个js文件不太靠谱，但是一个模块一个js文件则非常优雅。

ESM已经逐渐成为规范，语法上只要兼容ESM就完事了，其实也不需要什么特别大的改动，只是需要额外处理下import / export。

我用洗澡的时间思考了一下，import按正常的对象声明处理即可，而export处理方法则与其export的类型做同样处理，这样可以完全当成一个正常模块使用，例如某个文件import RPC函数，那么也是导入的封装后的函数，完全没问题。

关于遗留问题

私有对象还是很有必要的，我想到了一个非常优雅的解决方案：

众所周知，编译器可以找到那些不被使用的对象，所以对于不被某一端所使用的对象可以直接删除，达到私有的目的，当然这种做法在程序里包含了eval的情况下会失效，不过eval是一个比较危险的函数，大多数时候并不会使用，所以没问题，对于确实需要显式注明私有的对象，我们还是可以在语法上开洞。

关于对象RPC

好像很少有人谈到过这个概念，也可能这是我自己造的概念。

具体来说，服务器端的RPC函数可以返回一个对象，然后经过序列化发送到客户端，客户端反序列化成对象，一切都很正常。然而并不是所有对象都能够这么做，比如某些有函数的对象，显然函数直接序列化是没有意义的，这就丢失了信息，客户端如果去调用对象的函数就会得到一个错误。举个例子，服务器的RPC函数是打开一个文件并返回文件的handler，接下来可以使用这个handler对文件进行读写，但是经过序列化 & 反序列化后，客户端拿到这个对象是完全没有作用的，并不能直接对服务器的文件进行读写。

是真的不能吗？还记得Proxy吧，这就派上用场了，对于包含了函数的对象，我们用Proxy包裹成RPC，执行的时候发往服务端执行，然后再把结果反馈回来，这不就成了？

不过这是RPC的事情了，现阶段还在倒腾编译器，RPC以后再说吧。