You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: Maybe a bit unstructured and confusing - See it as first iteration :) If there are some questions or something is unclear, please let me know.
The headings export is currently auto generated via a remark (?) plugin ( Code ref ).
Which works fine in 99% of all use cases.
If we have some custom logic, we can currently override/extend them by defining our own headings in the page.tsx ( Example ).
This idea is for the approach, where we can't use the page.tsx and want to control the available headings via the current mdx file.
What needs to be changed?
Check if a headings export is specified in a mdx file
If so, use the value if it's not a function
If it's a function, call the function - here we should support async functions
We have to find a way to tell the @renoun/mdx package if it's necessary to generate the headings or not ( = loading the addHeadings function conditionally ).
Optional: While parsing the mdx file, we could also check if the returned schema/type matches the expected one - if not, throw/show an error?
Optional: making it "opt-in" ( via a feature toggle or via a global config? )
Some details:
In my template repo ( which reflects the structure of our internal docs ), I have different collections and the page.tsx is built as generic as possible ( multi-collection support? ), so creating the headings from the page.tsx wasn't an option for me without creating more complexity to the page.tsx.
Use case was to provide some functionality to render an openapi spec.
( as alternative, you could use the existing API Documentation )
One helper function to parse the spec ( here I use @apidevtools/swagger-parser )
One helper function to generate the headings based on the available sections in the spec
I know this could be an edge case and this approach would just move the "complexity" from my side to the package side.
I know there is a risk that supporting this could break some pages if they have unexperienced users who doesn't know what they're doing
The text was updated successfully, but these errors were encountered:
Something to note, imported MDX file headings also need be considered since only the root file is considered right now. The function should work nice for this to read in imported MDX files. For example, the remark plugin can wire this up by default:
It's a little more involved with having to index them properly based on where the import is used, but it shouldn't be too hard. What's nice is this API should solve two problems with one implementation 😎
I'm currently working on making the overall API stable, but will come back to this after the dust settles.
The
headings
export is currently auto generated via a remark (?) plugin ( Code ref ).Which works fine in 99% of all use cases.
If we have some custom logic, we can currently override/extend them by defining our own headings in the
page.tsx
( Example ).This idea is for the approach, where we can't use the
page.tsx
and want to control the available headings via the currentmdx
file.What needs to be changed?
headings
export is specified in a mdx file@renoun/mdx
package if it's necessary to generate the headings or not ( = loading theaddHeadings
function conditionally ).Some details:
In my template repo ( which reflects the structure of our internal docs ), I have different collections and the
page.tsx
is built as generic as possible ( multi-collection support? ), so creating the headings from thepage.tsx
wasn't an option for me without creating more complexity to thepage.tsx
.Use case was to provide some functionality to render an openapi spec.
( as alternative, you could use the existing API Documentation )
@apidevtools/swagger-parser
)Example mdx file:
I know this could be an edge case and this approach would just move the "complexity" from my side to the package side.
I know there is a risk that supporting this could break some pages if they have unexperienced users who doesn't know what they're doing
The text was updated successfully, but these errors were encountered: