Aurelia:同构？

据我所知,Aurelia不支持这里提到的服务器端渲染.

但问题是:是否有可能通过一些黑客/解决方法来做到这一点？

最明显的想法是使用Phantom,Nightmare.js或其他任何东西来简单地在服务器上的Chrome中呈现该页面并将其提供给客户端,但这很可能会导致很大的生产力问题.

谢谢!

根据Rob Eisenberg今天(2016年4月16日)对FDConf的回应,服务器端渲染将在2016年实施,有一个核心团队成员正在研究这个,并且这个功能有截止日期.

Universal/Isomorphic Aurelia有一个可以监控的未解决的问题.特别是EisenbergEffect(Aurelia的创建者Rob Eisenberg)表示他们正在逐步为Aurelia提供Universal支持.他发表的这篇文章提供了大部分细节:

EisenbergEffect于8月25日发表评论

我们正试图在下个月内锁定事情.这并不意味着我们之后不会添加任何内容,但我们需要努力实现稳定性,性能和可靠的文档,而不会分散许多新功能.

首先,"同构"不是我们想要解决的初始v1版本的用例.同样,这并不意味着我们以后不会这样做.但是,我们希望首先为基于浏览器的应用程序以及手机差距和电子/ nwjs桌面应用程序提供可靠的框架.这是我们最初的目标,我们希望确保比任何其他框架或库更好地处理这些场景.

在那之后,我们还有其他一些我们想做的功能,这些功能本身就很有价值,但也会让我们更接近于同构.

启用所有aurelia库以在服务器上运行.这可以实现一些新的测试场景,因此只有从这个角度来看它才有价值.

一旦代码可以在服务器上运行,我们就可以实现服务器视图编译.这不是同构渲染,而是在构建和捆绑过程中运行Aurelia视图编译器的能力.这使得可以提前完成更多工作,作为构建的一部分,然后不需要在运行时在浏览器中完成.因此,这将改善所有应用程序的启动时间并减少所有组件的初始渲染时间.它还可以将编译视图存储在浏览器本地缓存中,以提高应用程序连续运行的性能.

在这两件事都到位后,我们可以看看为每条路线做一个完整的服务器渲染.这在最真实的意义上并不完全同构,但它解决了SEO问题,而不需要第三方库.所以,在那里找到解决方案真好.

最后,我们可以将服务器预呈现的应用程序与在浏览器中运行的有状态Aurelia应用程序"同步",为我们提供100%的同构支持.那么,那些是阶段.前两个对所有开发人员都有好处,即使那些对同构应用程序不感兴趣的开发人员也是如此.今天的第三阶段可以通过第三方库来完成,所以对于那些不想要额外依赖的人来说,这对我们来说是一件好事.所有这一切都导致4增加最后的部分.

我们已经开始了一些关于1的工作.这可能会进入我们的第一个版本.我们不会推动它,但它已经在进行中,我们正在寻找问题区域,以便我们可以使它工作.步骤2-4涉及重要工作.真的,我们在这里讨论的是一系列功能,每个功能都相当复杂.因此,这些可能会在v1之后分阶段进行,作为点发布.

我们真的不想做Angular 2所做的事情.他们的架构大规模复杂化......以至于很少有人能够理解它并且用它开发应用程序变得更加复杂,有许多细微差别.我们真的不希望这样,所以我们首先关注我们想要的开发者体验,然后我们会回来看看同构支持(是的,我们已经有了如何干净利落地想法,但想要给那些一段时间成熟的想法).在所有这些中,我们的目标是模块化.所以,如果你不关心同构,你就不必去思考或担心它.如果你这样做,你将安装必要的软件包,同意系统的"约束",并在你的路上.

所以,对于所有对这个话题感兴趣的人,我会请你耐心等待.对于那些对同构不感兴趣的人,不要担心,我们不会扼杀开发者的经验.对于那些想要它的人,你将不得不等待更长时间,它将分阶段和模块化的部分,以免扰乱他人.

就在现在

我可以建议的唯一方法:使用phantomjs渲染页面+使用redis加速该过程.

但是在客户端恢复状态会有很多麻烦.

.......

脏的解决方案

从服务器和客户端加载呈现的页面以通常的方式呈现新的页面,而不是切换UI.

它不会是真正的同构,但首页加载时会像https://github.com/rails/turbolinks.

.....

我希望很快Aurelia团队能为这个案例提供更简单的东西.