$site referencing to siteDataByRoute

Spawn from a discussion in https://github.com/vuejs/vitepress/pull/152

About siteDataByRoute, if $title and $description are localized, I think $site should also be localized pointing to siteDataByRoute instead of siteData. I think that users accessing $site from the markdown, should really be looking for $siteDataByRoute.

In enhanceApp siteData actually means siteDataByRoute: https://github.com/vuejs/vitepress/blob/master/src/client/app/index.ts#L118

export default {
  Layout,
  NotFound: () => 'custom 404',
  enhanceApp({ app, router, siteData }) {
     // `siteData`` is a `ref`` of current site-level metadata. <- this is really siteDataByRoute
  }
}

So it makes sense for $site to follow suit.

We will be breaking compat slightly here with vuepress, but I think this is a good change that will help avoid i18n issues and it will be really confusing that siteData from enhanceApp is not the same as $siteData in vitepress.

If we do this change, we could expose unlocalized siteData with another name. Maybe $unlocalizedSite?

[kiaking]

Very good point. Yeah the $title should have been $documentTitle really 😅 , Well it’s “site’s title”, “page’s title” so the name is same, but technically different thing (I’m just telling it to convince my self here 🏃)

For now, I’ll fix the inconsistency to close this issue. Let’s think a bit more about the naming of $siteByRoute before we expose it.

[kiaking]

Maybe it is just a matter of finding a good name

Yeah I’m very open to discuss this. I think putting under $page might make sense, but not so sure. Since $page is really the page it self, and nothing more I think. And I’m talking page I mean the markdown contents. So even you remove sidebars, navbars and everything, page should have no difference. It’s a page.

Where else, site is a whole site, even though it is localized. It contains sidebar, navbar, which page do not care. Again, if we were calling the $page to be $content, for example, maybe it would have made sense to name $siteByLocale to be $page 🤔

And while I was trying to come up with different names, I also felt like maybe it’s going to be confusing to have almost identical stuff in a different name, or in different place. $site and $page.site is same thing (without i18n), but it’s not top down you know what I mean. It’s different from having $site.themeConfig and $themeConfig, where it’s just a shortcut.

At least, I would like to change it to $siteByLocale, instead of $siteByRoute though. Technically $siteByRoute is more correct in terms of implementation, because it’s really a route (path) checking, but as a domain point of view, it’s locale specific feature so 😳