【问题标题】:Is Angular 2 Not Appropriate for Multi-Page Apps? [closed]Angular 2 不适合多页应用吗? [关闭]
【发布时间】:2018-08-15 12:45:19
【问题描述】:

我有一个使用 angular2 的多页应用程序的工作示例。在本地开发时,加载时间似乎比我希望的要慢。

我在 stackoverflow 上阅读了另一个线程,它显示了如何设置这种情况:How to use Angular2 as a non-SPA?

这确实有效,但我觉得它会减慢您的应用程序加载时间。

在多页面应用程序中使用 Angular2 的最新技术是什么?可行但不是最佳实践?对于这类事情,React 是更好的选择吗?请提供一些观点。

请注意,这不是一个重复的问题,询问“如何”在多页面应用程序中使用 Angular2,而是询问由于在每个页面上加载应用程序等是否被认为是不好的做法。

另外,就我需要多页应用程序而不能使用单页应用程序的原因而言,是因为我的应用程序是数据驱动的。 SEO 很重要,而 Angular 在这方面似乎有所下降。 Prerender 和 Angular Universal 似乎并没有为我的用例削减它。

有什么想法吗?

编辑:

有一些问题问我为什么要这样做。以下是对评论者的回复:

“我需要一些高度交互的页面,使用 Angular 更容易实现。另外,能够跨项目共享组件也很棒。”

【问题讨论】:

  • Is React a better choice for this type of thing? no - imo react 从不 比 Angular 更好。我想你正在寻找这个:angular.io/guide/router
  • @messerbill 你好,messerbill,我以前用过路由器。它不会削减它,因为页面的内容不是由搜索引擎呈现的。当然,谷歌有点渲染它,但它在我所做的事情中受到了打击或错过。另外,我需要其他搜索引擎来索引我的网站。
  • 有几种方法可以解决这个问题——也许这可以帮助你:coursetro.com/posts/code/68/…
  • @messerbill 嗨,messerbill,我在使用 Angular Universal 时遇到的问题之一是缺少 Java 支持,即 Spring Boot。
  • the lack of Java support 什么意思?您可以通过通常的ajax requestsSpring Boot 等 Java 服务器进行通信(就像与任何其他服务器系统一样:node、php、c#....)

标签: javascript angular typescript frontend


【解决方案1】:

我从来没有想过这个。

我的直觉是缓存将是你最好的朋友。当您构建应用程序时,它将按供应商和应用程序(或您的情况下的页面)类型拆分您的资源(包括 js、html 等)。供应商通常不会在页面之间发生太大变化,并且是最大的。因此,如果您可以隔离该部分,您应该在服务器和浏览器缓存命中方面获得不错的性能提升。

这里列出的内容不会因页面而异,包括

  • 静态资源,例如。图片
  • index.html 引用的资源,即使你有多个页面,但里面的大部分引用都是一样的。角度供应商文件。
  • 您的组件模块库,如果您将其隔离出来,它将是另一个要包含的供应商模块文件。

总体而言,您应该测试未更改的内容是否坐在一起。如果您最终得到三个主要文件,其中两个在页面之间完全没有变化,那么这将是一个宾果游戏。否则,它肯定会很糟糕。

我被告知的另一件事是服务器渲染,如果所有内容都在那里渲染,您可能可以自己控制相当多的缓存。尤其是当您关注 SEO 时。

【讨论】:

    【解决方案2】:

    而不是一些一般概念,我有以下想法,假设您需要构建 10 个页面。

    • 连接服务器以使用不同的 url 访问相同的 index.html;
    • 读取url参数,判断哪个url命中了这个文件;
    • 移除所有有角度的内部布线
    • 相反,请使用ngIf 自定义编码路由,因为在您的情况下,角度路由是无用且具有误导性的。 您可能需要为正确的页面打开正确的DOM

    您最终会导致服务器一次又一次地访问同一页面(同卵双胞胎),因此您实际上是在为 SPA 提供服务,只是这次是针对多个 url。

    如果我必须构建 100 个页面怎么办。

    你有一个更好的武器,因为你可以在 product.html 中放置 10 个页面,在 admin.html 中放置 10 个页面。这个想法是

    • 移除角嵌套路由
    • 使用Html分割url或子url

    这个想法可以很容易地扩大和缩小规模,并且真的可以追溯到 10 年前的传统 Web 开发。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-09-05
      • 1970-01-01
      • 2013-01-08
      • 2021-02-13
      • 1970-01-01
      • 2011-04-09
      • 2013-04-07
      • 2015-05-17
      相关资源
      最近更新 更多