Heim > Fragen und Antworten > Hauptteil
P粉9868609502023-09-05 12:44:28
你是什么意思?
在这里,我们只谈论页面,对吗?所以是/user/id
,/post/id
等等?
如果是这种情况,你可以有一个/_entity/id
,甚至是一个/_entity/_slug
,以获得更大的灵活性(_entity
可以是user
或post
等等)。
如果你有很多不同的页面,比如/about
,/our-team
,/careers
等等,我想这些页面都需要有自己的SEO、内容,并且是完全合法的。
我真的不明白为什么这会成为一个问题。它将被正确组织、可扩展,并且不会有太多的抽象(在我看来这很重要)。
你还可以通过nuxt/content
将其中一些页面导出为.md
文件,并将其导入到页面中。就像Nuxt文档所做的那样。
如果你真的需要简化这些页面,你可以使整个模板动态化,并在运行时生成标记。这可能会引入一些巨大的复杂性,可能并不需要(在我看来)。
此外,布局、插槽和渲染函数也可以是一种解决方案。
我不确定微前端(对我来说听起来像个炒作词)实际上是Nuxt的几个实例相邻放置(如果在同一域名下托管的话听起来像个可怕的想法),还是你的非单体全栈应用的“组件化”(几年来我们构建网站的方式)。
但对我来说,如果一个项目有100个pages
,完全没问题。
当然,硬编码一些/blog/post/1
,/blog/post/2
是不好的(哈哈),但一个大型应用完全没问题。这可能会在构建时间等方面引发一些问题,但这是另一个话题,更多地取决于你生成项目的方式。
所以,是的,如果你的面试官想要深入了解这些方法之外的东西,你需要从他那里获得更多细节,以确切了解面临的挑战和可以使用的方法。
简而言之:据我所知,没有框架旨在减少页面数量,因为这本身不是一个问题。10k个Nuxt页面不会以任何方式使你的/about
变慢(如果确实如此,问题在其他地方)。