What content we should show in root component page?

[dacsang97]

In build page script, I write a draft to show a list component for the root component page (/${prefix}. Default is /components).

vuepress-plugin-component-docgen/src/build/pages/pages.ts

Lines 46 to 47 in 621f877

	buildIndexPage({ dirContext, componentContextMap }),
	...buildComponentPages({ componentContextMap }),

Should we generate the content this page or allow user customize (same basic example, you write components/readme.md ?

[flozero]

The thing i see about this is that.

Sidebar as two types:

Groups and multiples.

In groups it's one sidebar everywhere that ou can disable in some pages.

guide/
etc/
etc/
components/
etc/
etc/

In this case If you dont create a components folder inside docs/ that as a readme.md the root. He will create a page when you come into components that tell the structure

components/
etc/
etc/

If you create the readme it will take it. Check my branch in codesandbox i added it i think

So i think answear your question. It depend First we should check if in multiple sidebar it does the same as group. And if yes we should generate if not i dont know

[flozero]

We maybe improve first the what structure we create.

Because for now it juse create a structure like this

components/
every components at the same root level even if they are not

Maybe we should consider about it?

[dacsang97]

Should we support readme.md file to write example for the component (same vue-styleguidist). So we have 2 options:

• <docs> block inside the component file
• readme.md file

[dacsang97]

About structure, I think we will refactor code to support hierarchy instead of all component shown in the root.

[dacsang97]

Link and sidebar will base on folder structure.
Example:
Folder: /components/atoms/Button.vue
=>

Link: /components/atoms/button
Sidebar:
Atom
  Button

[flozero]

1rst point. I am not sure it is necessary even if vue-styleguidisit support it. I think it's better to choose one or another no ?

2nd point. Yeah i agree but it will depend on what we can do with sidebar. For hierarchy. We can just do that with the multiple sidebar no? We cannot do it with groups sidebar because we can't do children of children but maybe i am wrong. And in the multiple sidebar we can have 1 depth hierarchy. We need to think more about it.

3rd Yeah with that structure in multiple it can work i think. Maybe it can be good to let the user choose an option?

In group it's automatically in the root ? And for multiple we can let them choose root or split?

[flozero]

I am actually commenting all the code for a better understanding of all for me

[flozero]

Actually multiple sidebar look like this

[flozero]

I am inspiring about this.

https://github.com/vuejs/vuepress/blob/master/packages/docs/docs/.vuepress/config.js

It actually using groups + children. With this we can create what you wanted

like

atoms/
       Button1.vue
       Button2.vue
molecules/
       Button1.vue
       Button2.vue

We can focus on that and the other case in multiple sidebar

sidebar: [
      {
        title: "Guide",
        collapsable: false,
        children: ["/guide/"]
      }
    ]

We can throw an error for this and explain why we do not do that ? or add all components we found in the root structure

[dacsang97]

I really like your idea

[flozero]

I think it's not hard to implement just change the directory structure.

You want to work on it ? I can but first i need to finish my pr and I need you to validate it and answear to my question about codesandbox

[dacsang97]

Okie I will fix it :D

[flozero]

Tell me if you work on it or if you want i work on it :)

[dacsang97]

I will work on it, you need to concentrate on Codesandbox 👍

[flozero]

i finished it for the first version.

Maybe we can add global require that needed to be injected into it

[dacsang97]

How we show sidebar if the component in sub-directory has a level > 1.
Sometimes, I don't use Atomic design for some project, or in the other word, it looks like this:

/components/
  /common/
    /text/
      Heading.vue
      Quote.vue
   /form/
     Input.vue
  ...

[flozero]

Hum The user should avoid this I think. we should limit at level 0 and 1.

Or maybe you can add the sub level in the name like text/Heading But it is not possible to do this with the actual sidebar from vuepress.

One thing could be to show multiple preview component in one readme but it will be hard. For the first version maybe we should focus on one thing.

If level > 1 add a root children to the level1 that i can access when i render the component with codesanbox to add it to the context of the app

Or more simple do nothing and the user will have to add it manually in some global require

[flozero]

I am actually working in Leroy merlin a big french company i will use this plugin to test it with global require when u have finish

[dacsang97]

we should limit at level 0 and 1.

Okie, I think we need this rule.

[flozero]

Did you create a branch ? Any updates :) ?