VueJS: cons of component structure?

Question

Vue.js

Guys, comment on the possible disadvantages of the component structure for a large application.

src
    components
        icon
        layout
        main
        modal
        shared
        ui

these folders contain folders with components, here is an example with the main folder

main
    Header
        index.vue
        Menu.vue
    Sidebar
        index.vue

Each folder is a namespace for a component.
An example with a couple of components:

<MainHeader />
<MainSidebar />

Nested components of the child components of each namespace have the prefix of the component in which they lie.
For example, the Menu.vue component, which is located in the Header folder, will have name: 'MainHeaderMenu' and like this when describing:
<MainHeaderMenu :list=”menuList” />
With such a structure, it is quite easy for me to navigate the code, I can immediately see by the prefix from which namespace the component is, and everything is structured , as for me, with such a structure, you can add hundreds of components.
The only thing that annoys me a lot is describing components with a UI namespace:
<UIButton />, <UISelect />, <UIMenu />.It is very inconvenient for me to read a component when it has a UI prefix, I don’t know why, but it breaks my eyes. Can't think of anything else.
In general, please tell me about the structure, maybe what things I have not yet provided for and your comment will help me.

Answer 1

A few general considerations:
1. If the project is developing, and you are not rewriting something that is already ready, then at the initial stage there is no point in bothering much with the structure. Just do timely refactoring and bring the structure to a more convenient form as you develop.
2. From experience, it is more convenient to have a flatter folder structure, otherwise it will be very difficult to navigate through them over time.
3. In your version, you will get many identical index and menu files, for example. As a rule, a bunch of files are open in the editor, there is little space for the title and you will end up with many index.vue tabs. Those. it is better to make the file name more informative like:
header\
HeaderLayout.vue (or Header.vue or HeaderBase.vue ) is a base component that others use in one way or another.
HeaderMenu.vue
HeaderTitle.vue
etc.
Personally, I usually make the component name equal to the file name.
4. If you haven't looked, you should read the vue style guide: https://vuejs.org/v2/style-guide/
5. Closely related files and folders are best kept close to each other for easier searching.
6. For base components, to distinguish them from framework components, for example, you can make your own prefix like app-button, app-selector, etc.

Answer 2

Read nuxt.js - there best practices include file hierarchy.

Answer 3

It all depends on the requirements for the structure. Depending on them, the key parameter is determined with respect to which the structure is designed. Your structure is oriented towards inclusion, the disadvantage of this is confusion in cases where components/modules overlap in the tree, for example when 2 branches use the same component. That is, this structure has extensibility limitations. I prefer a structure focused on areas of responsibility. That is, it is a horizontal structure. Its main drawback is the canvas of files and folders in the browser, so you can’t do without interspersed with hierarchical folder structures (it’s worth thinking about 100 times). On the other hand, it allows you to easily navigate in the functional modules of the system and group its functionality inside the folder with the module (does not go beyond the task of the module,