Yeah it's not complete don't use this

If you create a component/composable/page etc with the same name in a higher layer it will override the existing one.

Not sure what you mean by that. The idea of Nuxt layers is to "extend" layers not override them. Can you share your use case?

In simple terms, your final app will be all your layers merged together. The end result might be your 'top layer' app using components/utilities provided in some lower layers or like in the video an app where pages and their functionality are separated via layers and merged to create an app with multiple pages.

@@M-lt6kx I understand what you are talking about but I thought layers was something else. I have a ui layer that other Nuxt installations can use. Pnpm monorepo manages all layers. That is how they worked in Nuxt 3. Maybe they are ditching this concept

​ @nyambe Layers can be used for multiple purposes. Yes, one way is to share them among projects. But they cal also be used to implement a DDD/modular architecture. Take a look at the official docs.

Your layers can be anywhere. In any folder locally, in an npm package or in another git repo. Any of the supported package managers will allow this.

Why do you care what JavaScript devs do?

@@codingwithmartin3177 i like technology as a whole. dont want my bethrens suffering

Nuxt also has an upcoming multi-app feature which is for micro frontends. But layers is simply a way to group your monorepo app into logical features and it's completely optional.

Layers is more about grouping your app into logical units like "users", "settings", "sales", "blog", "auth" etc. So you can work on your "settings" feature and find all files related to settings in that layer. This is especially useful in larger apps with bigger teams where one team or developer might work on settings feature, another developer can work on users etc. without conflicts. It also gives the app nice, clean structure.

@@QueeeeenZ Yes, I understand the layers concept and agree with you, but my comment was meant more on "each layer can have its own config" - I was wondering how often in real life I would need a different config file for each layer :) But I don't insist that there aren't use cases for that, especially for large apps :)

Oh, I see what you mean. I have created large scale apps with layers and I have never needed to specify a different config for each layer. The only difference between layer configs was to specify where to find imports, components etc. because it's a different directory for each layer.

That is the whole thing about GObject, they give you a framework to create inheritance, polymorphism, even introspection and then use it to implement GTK, which is a high level GUI framework. The thing is that there is no automatic way to create vtables as in C++, you do it in code yourself during class init. For example Inheritance is done with structs where the parent pointer is the first member of the current class struct. So you can cast a pointer to your object to a pointer to parent class object without anything breaking. So methods/functions that expect a parent object instance can work seamlesly on a your current object.

Another feminist that is upset about nothing...

​@@Turjak_art what does this have to do with feminism? and this is valuable criticism that improves his communication and let's his ideas/content be conveyed more clearly. this is basic communication skills

​@@FlanPoirot because you're a weak minded person that had such a hard time I feel so sorry hearing that you had to push thru.... Crying about this little issue must be hard for you. did you survive it?

i completely agree. i tried using gtk for some test utilities i needed, and quickly decided to move on to Qt. Following a tutorial is fine, but when i can't look at glib's documention and understand it, then there's a big problem. you'd think all the money and time from RH that goes into g-stuff that this would be better. i dont understand how g-stuff is popular.