Shorten the composables api

[Mister-Hope]

We are all using $page $frontmatter $lang in V1, and we are familiar with it.

In my opinion the composables api is too long now.

I think we should provide a short one @meteorlxy , here is your code in theme default:

  import { usePageData, usePageLang, usePageFrontmatter, useSiteData, useSiteLocaleData, useThemeData, useThemeLocaleData } from "@vuepress/client";
  const lang = usePageLang()
  const frontmatter = usePageFrontmatter()
  const site = useSiteData()
  const siteLocale = useSiteLocaleData()
  const page = usePageData()
  const themeData = useThemeData()
  const themeLocale = useThemeLocaleData<DefaultThemeOptions>()

So why not just use:

  import { usePage, useLang, useFrontmatter, useSite, useSiteLocale,, useTheme, useThemeLocale } from "@vuepress/client";
  const lang = useLang()
  const frontmatter = useFrontmatter()
  const site = useSite()
  const siteLocale = useSiteLocale()
  const page = usePage()
  const theme = useTheme()
  const themeLocale = useThemeLocale<DefaultThemeOptions>()

It's easier to read and write.

I think we should provide short ones for alias intead of forcing people to use long api name.

[Mister-Hope]

Besides another thing is confusing me.

We are using the word themeConfig in config. And also we are using app.option.themeConfig to access it in clientSetup and pluginFunction. But the USE API is called useThemeData. I am worried that this may confuse the new comers.

[Mister-Hope]

Also by the way, are $lang $themeConfig and other computed variables in V1 available in V2?

Currently I will get types error when trying to visit those like this.$frontmatter

[yzx9]

I guess no, vue3 recommend functional-base APIs that allow better type inference.

[Mister-Hope]

You are thinking to little bro. So I have to write like this to attach frontmatter in template?

<template>
   <span>{{frontmatter.xxx}}</span>
</template>

<script>
import { defineComponent } from "vue";
import { usePageFrontmatter } from "@vuepress/client";

export default defineComponent({
  name: "XXX",

  setup() {
    const frontmatter = usePageFrontmatter();

    return {
      frontmatter
    };
  },
});
</script>

when I can do this in V1

<template>
   <span>{{$frontmatter.xxx}}</span>
</template>

Only providing composables can make it hard to access them in template. That's why vue-router is still providing $router and $route

[yzx9]

Okay that makes sense.

[meteorlxy]

https://github.com/vuepress/vuepress-next/blob/55f780c4a516b2c0119328874906647af80ac73b/packages/%40vuepress/client/src/app.ts#L140-L192

[Mister-Hope]

Got it, but I got type issues when access those in typescript, I serach the source code, but I do not find any type inject to defineComponent. ( I would more prefer a smoother migration intead of changing all to composition api at one time)

[meteorlxy]

Here is my consideration:

Explictly mark the scope of the data

In fact, I think the configuration scope is what really makes new comers confused. So I tried to explain it in v2 docs: https://vuepress.github.io/guide/configuration.html#config-scopes

That's how I named those useApi:

• siteData, siteLocaleData - Site scope
• themeData, themeLocaleData - Theme scope
• pageData, pageLang etc. - Page scope

For example, useLang and useSite just looks like the same scope. But in fact they are "the lang of current page" and "the data of the whoe site".

So I personally prefer to keep those scope prefix.

---

As for the themeConfig, I'm thinking about removing siteData.themeConfig.

Now we simply put everything in themeConfig directly into site data. But it might be better to let theme authors to determine what data they want to pass forward to client side.

I'll open another discussion for that.

[Mister-Hope]

Here is my consideration:

Explictly mark the scope of the data

In fact, I think the configuration scope is what really makes new comers confused. So I tried to explain it in v2 docs: https://vuepress.github.io/guide/configuration.html#config-scopes

That's how I named those useApi:

• siteData, siteLocaleData - Site scope
• themeData, themeLocaleData - Theme scope
• pageData, pageLang etc. - Page scope

For example, useLang and useSite just looks like the same scope. But in fact they are "the lang of current page" and "the data of the whoe site".

So I personally prefer to keep those scope prefix.

I came up with it.
Just wonder if some alias can be exported, while marking them Alisa for xxx in JSDocs. I found it hard to read and type with those long api names.

It's hard to catch the point you want with a glance, especially the case you choose to use the same variable name as api:

  const pageLang = usePageLang()
  const pageFrontmatter = usePageFrontmatter()
  const siteData = useSiteData()
  const siteLocaleData = useSiteLocaleData()
  const pageData = usePageData()
  const themeData = useThemeData()

[Mister-Hope]

Also I think it's good to keep the apiname and the computed variables align.

Whats your opinion about it?

https://github.com/vuepress/vuepress-next/blob/55f780c4a516b2c0119328874906647af80ac73b/packages/%40vuepress/client/src/app.ts#L140-L192

[meteorlxy]

The computed variables are mainly used for v1 compatibility.