-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat: Implemented MDX component management for enhanced documentation capabilities. #22
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works and is amazing! 🚀
I wrote some comments!
No-code platforms are breaking down the barriers to innovation, allowing | ||
anyone with an idea to bring it to life without needing to write a single line | ||
of code. | ||
</Callout> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is easy to understand for me 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Gyu07 This is how we plan to write it.
@@ -30,14 +31,14 @@ export default function Page({ params }: PageProps) { | |||
|
|||
return ( | |||
<article> | |||
{/* <Callout /> */} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this debug code?
@@ -0,0 +1,18 @@ | |||
import type { MDXComponents } from 'mdx/types' | |||
import { useMDXComponent } from 'next-contentlayer/hooks' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm...
If it depends on the logic of next, this @packages/mdx-components is not a pure React component, and the benefit of splitting the package.
service-site/features/mdx
looks good to me, but what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MH4GF
I struggled with how to handle this part. The reason I wanted to split it into a package was to clearly define which components article writers can use within MDX files.
I was concerned that managing components within src/features/mdx/components would result in deep nesting and make the structure less clear due to the mixing of development code. 🤔
However, I agree with @MH4GF's point that the code being dependent on Next.js logic feels out of place.
I've been considering a new idea: What if we manage these components in the same directory where we manage the articles? 👀
/
└─ src
└─ contents
├─ posts
│ └─ 1/en.mdx
└─ components
└─ Callout
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@junkisai I see. Thanks for your consideration!
What if we manage these components in the same directory where we manage the articles? 👀
Looks good if it works!👍🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MH4GF
I've implemented the change to manage the components in the same directory as the articles!
refactor: Integrate MDX components into service-site and remove separ…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀
@@ -17,6 +18,7 @@ | |||
"fmt:biome": "biome check --write --unsafe ." | |||
}, | |||
"dependencies": { | |||
"clsx": "^2.1.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Summary
Related Issue
Changes
Testing
Other Information