feat: various configurations are very confusing to use

[hairyf]

I'm having a problem while developing a theme, there is no way to control about the vue app i.e. the app context

and because the configuration is not in the node environment, it is almost impossible to control the app conext through theme config

It is in setup/main.ts in demo, combined with valaxy.config.ts / valaxy.config.ts, or node/index.ts in theme

I find the configuration is getting more and more confusing once it's in use

For example, I want to make more extensions to app ctx in the theme, does that mean that there should be files in theme/[??].ts to control app ctx

Then the actual use will appear the following configuration

• demo/setup/main.ts
• demo/valaxy.config.ts
• demo/vite.config.ts
• theme/node/index.ts
• theme/[app ctx??].ts

[YunYouJun]

Control ctx in theme/setup/main.ts

had been supported

import { defineAppSetup } from 'valaxy'

// eslint-disable-next-line @typescript-eslint/no-unused-vars
export default defineAppSetup((ctx) => {
  // router.isReady().then(async () => {
  //   const { registerSW } = await import('virtual:pwa-register')
  //   registerSW({ immediate: true })
  // })
})

[hairyf]

Ok, let's go back to the question of app ctx, I found that defineAppSetup is defined in the source code, which seems to be preparing for the later work, its use seems to be like this

Assuming the theme already supports - theme/[app ctx??].ts

import { defineAppSetup } from 'valaxy/client'
export default defineAppSetup((ctx) => {
   ctx.app.use(...)
})

It seems to be able to expand some functions

But if I need to use some higher order components, I have no way to define

Example: A Simple ConfigProvider Component

import ConfigProvider from "./ConfigProvider.vue"

export default defineAppSetup((ctx) => {
   ConfigProvider // how to use ?
   ctx.app.use(...)
})

[YunYouJun]

Write components in components folder, they will be registered automatically.

The order (components with same name) of override is userRoot -> themeRoot -> clientRoot.

[hairyf]

Write components in components folder, they will be registered automatically.

The order (components with same name) of override is userRoot -> themeRoot -> clientRoot.

No, of course I know it can be defined, but this is a global higher order component, how do I make sure it's at the top level

[YunYouJun]

I don't think themes should have components that the user can't override.

[hairyf]

some suggestions, I can understand that the valley.config.ts makes a lot of trade-offs to ease the user's work, but it's not necessarily good

Some radical ideas, let's develop back to simplicity

userRoot

• valaxy.config.ts

There is no vite.config.ts , it is included in the valley.config.ts

export default {
    // I can define the root component here
    // In vitepress, it is defined as Layout
    root: Component,
    enhanceApp(ctx) {
       // here is the context control
    }
}

themeRoot

Its function is the same as above, it does not need to be compiled

• valaxy.config.ts

Consistent with the above, inherit the call from enhanceApp of userRoot

• main.ts/index.ts

All configuration of the final frame only

• demo/valaxy.config.ts
• theme/valaxy.config.ts
• theme/main.ts or index.ts

[YunYouJun]

I actually don't think it's getting any easier.

Vitepress doesn't have a layout system, so it has to register by ourselves. It also has an uncoverable or cumbersome layout, which I hate. It is also important that blogs have more layouts than documents(vitepress), such as tags and albums.

valaxy.config.ts should be a pure object like hexo's _config.yml and should not have complex function content. The user can even still choose the YML format. This is helpful in attracting users to migrate.

[hairyf]

You may have some truth in what you said, I look at the problem from the perspective of a developer

[YunYouJun]

Actually I have some doubts about user control. I think users should not manage various controls such as pages, components, vue, etc. If the user wants to control, it is more reasonable to customize a theme or inherit the configuration of the theme

A user can customize a theme, but he may only want to modify a certain part of the content. Just like demo/yun does, he just wants to change and overwrite the footer while maintaining updates to the original theme.

If users don't want to control additional features like Vue Pages Components, they don't need to create them. This has no impact on the user experience. But we have to support this capability when the user needs it.

[hairyf]

ok i agree with you, i saw that createClientSetupPlugin supports this and it's pretty good

[YunYouJun]

Thank you for your advice, but the current design is also based on certain considerations, so without greater advantages, we do not plan to change the way it is used.

If you have any other ideas please feel free to share them with me. Thanks.

[hairyf]

Actually I'm probably just confused by the various lack of entry

For example, how is style/[??] introduced and where is the entry For example, setup/[??] I don't know without looking at the source code, all its files will apply

This is different from regular vue / docs application development, and its entry is very peculiar

Rather, it has no entrance, all content is scattered

maybe just not having a good documentation explanation

[YunYouJun]

After I've written a document, I think they'll all work out. I am writing a new document topic, I will speed up my work.

[YunYouJun]

I created a simple description file.

https://github.com/YunYouJun/valaxy/blob/main/demo/yun/pages/docs/guide/extend.md

English documentation and more details will be ready later.