Feedback on app.config
Tahul opened this issue · 0 comments
Hey,
I tried app.config feature that has been merged in framework, from a basic project and this branch in Docus that replaces @nuxt-themes/config by the usage of appConfig ; here are my few feedbacks on it.
Some references:
1. API
I've seen the PR mentions a crossed task:
Inject $appConfig (A plugin can easily inject reactive shortcut. Delegating addition to next steps)
I think this is one of the reason to exist of this feature, I would love to make it happen with some context.
@nuxt-themes/config existed to strictly enforce a way to declare and access the configuration for a theme.
Enforcing it makes it easier for an editor to be build on top of this feature, not only an editor for the actual config file, but also an editor that allows the injection of the available keys from this config file into specific slots such as components props.
Also, having an enforced way to access these variables makes it really easy for us to detect the presence of these variables inside any .vue file in the user app, which makes it easy for modules like nuxt-component-meta to enrich the Studio experience based on these scoped datas.
With current version of appConfig, we can expect theme authors to implement these logics themselves (as suggested, via a $appConfig shortcut, or any other non-standard way to do it) which removes most of the purposes of the work done on previous iterations.
What we had in @nuxt-themes/config was $theme('my.config.key.path') available everywhere, with a proper type generated for my.config.key.path for every available key in the theme configuration object.
Not only this was super convenient to use in any place of the app, but also was super easy to parse in the component code AND imagine being a kind of input inside a Studio form.
2. Deep merging strategy
As seen here, the app.config file will follow the same merging strategy as extends feature, which is not exactly what we want for this config specifically.
This config is made to be partially overwritten by the end-user, while fully declared by the theme authors.
One great example is icons, that you can see here:
In that example, you can see that the theme.config file does not allow setting defaults for any key that is an array, as defu default behavior will lead to merging these arrays, which results in having both the defaults defined by the theme author and the values written by the theme user.
Maybe it's okay but I think it should be clearly stated that theme authors cannot define defaults for array keys or they will be shipped to the theme user project anyways.
3. Schema support
theme.config file has support for export const schema that would allow theme authors to do deeper in the definition of their theme configuration.
This schema followed untyped schema for now, but was thought to be improved in order to support form generation feature from Studio.
Not only this allows to improve the typing and general developer experience for theme authors in the long run, but this also was built with the Studio in mind.
Exposing a schema makes it a lot easier for us to build an editor on top of this configuration.
A configuration key in VSCode is extremely simple to edit, but building a whole human-readable form around it gives the need to encapsulate it around other datas.
I'm afraid that without being able to specify a schema for the theme configuration, we won't be able to make the form look great for end-users (=== users of the Studio).
Also, schema makes it a lot easier to recompose a valid JS/TS file for configuration from a form, which also makes it easier for us to skip having to maintain AST logics for this to happen.
4. Metas
This is a side-purpose, but I think we should start thinking on how people should define values like title, author, and other meta-values for their theme, being able to watermark a theme.
Dropping @nuxt-themes/config in favor of this feature also completely removes this concept from the stack, which has I think some value.
Theme authors can watermark their theme.
Theme users can know what theme they are using when the project boot.
This was built with the intention of not making it look like an extended Nuxt project was "vanilla" Nuxt, as it can easily be mistaken if this information is not provided somewhere else.
But also, this also was a way to enforce some ways to supply some data, as the Studio in the long run should I think be able to provide some kind of marketplace around that theming feature, which I think cannot be properly built without providing these datas in a standard way from the theme itself.
Feeding both the direct output for developers and the end-user UI with a single source of truth for these datas seemed the good approach.
5. Extendability
I see that documentation for the feature says that we can define a theme key inside app.config, yet I don't really understand what is the point of other keys in that config file?
Do we want module authors to actually use that configuration file instead of a nuxt.config key?
What is the proper way to reserve a key in that config file?
In these lines I can see that I could somehow extends these config files, how should we do that exactly?
This feature sounds like a lower-level / more generic approach than what @nuxt-themes/config is, but not being generic was most of the purpose of that module.
If we want to ship some valuable (marketable) features to a user-base with a product, we ultimately have to narrow down the scopes of how people should use our tools that are built to be generic, or it will take years to cover all the possible use-cases with a product that provides an understandable user-experience.
What I expected from integrating the concepts of reactive/hmr-compatible configuration files into Nuxt core was to have a set of utils that would have make my life easier when it comes to add a configuration file linked to the Nuxt project.
I thought it was going to kill the need for modules such as Tailwind, Design Tokens, nuxt-themes/config, and probably others, to maintain their own way of loading configuration files, and that sounded amazing.
I would love to get guidelines on how to remove or adapt @nuxt-themes/config to that new features, while preserving the features.
Thanks for reading the issue and for all the efforts put into pushing these features into the framework! 😄