-
Notifications
You must be signed in to change notification settings - Fork 195
Support content "sections" #209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Interesting proposal. This sparked a couple thoughts. Equivalent Work with ContentlayerI'm curious what this would look like to build manually, given Contentlayer's current abilities? Would you build it all as a single model and use server-side JS to manipulate it all into a tree of docs? How messy is that? It could be helpful to see the equivalent code. This could provide insight into what exactly a feature like this should contain and what the shape of the API should be. Plugin System / Community PluginsAfter also commenting on #210, this has me thinking about what a plugin system might look like. Suppose we didn't build this feature. One way to help others achieve it is with an example. Another is to enable processing plugins that could build objects/relationships with content. Then the community could build self-encapsulating plugins to share. CL then doesn't have to add opinion to its base, but the community could streamline common patterns. @lucperkins What do you think of this? @schickling Have you thought about community plugins? Maybe we should open a separate issue to discuss? |
@seancdavis There may be a way to do this in CL at the moment, but it's not really coming to me. The issue is that it requires not just pulling in documents à la |
@seancdavis To make this more concrete, I threw together an example repo: https://github.com/lucperkins/contentlayer-sections-example It's pretty basic but I think that it shows the kind of input/output that I, personally, have relied on pretty heavily when using Hugo across many projects. There maaaaaay be a way to do something like this in CL currently, and I'm all ears if so, but I'm currently not quite seeing it. This might be a bit inscrutable because of the Go templating, but here's an example of a sidebar that I made (using Hugo, Tailwind, and AlpineJS) that relies fundamentally on Hugo's nested sections feature: https://github.com/vectordotdev/vector/blob/master/website/layouts/partials/docs/sidebar.html. |
Okay, @lucperkins — I see what you're looking to do here and why it's a hairy process. It's almost like we could open up some sort of lifecycle hooks so that you could use values of some content (i.e. There are meta values generated by CL that could help, but yes, definitely a cumbersome task right now. |
One of the things that I really like about Hugo is its sections feature, which enables you to separate nested directories of content into well-defined groups. So instead of a kind of "flat" array of files you end up getting a nested structure like this:
As expected, sections can be infinitely nested and each can have its own metadata. I don't necessarily endorse the way that Hugo does this (you need to sprinkle
_index.md
files throughout your tree) but I do think that having this kind of rich structure available to you is great for creating tables of content, sidebar navs, and all of that good stuff. Personally, it's the thing that I'm missing the most as I cross the chasm from mostly doing things in Hugo to doing things in JS world.I could envision being able to do something like this in Contentlayer:
This could export an
allDocsSections
object of typeSections<Doc>
that would enable you to recurse through the tree.This is very off the cuff but hopefully provides some sense of what I'm suggesting. I'd be quite happy to help out with this if others find the idea compelling. Just wanted to register it here in this forum.
Note: Docusaurus also supports this using a
_category_.{json|yml}
file that creates a new "category" (basically an analogue to the sections concept) wherever it's found in the directory tree.The text was updated successfully, but these errors were encountered: