Feedback for /docs/ui/llms

[fumadocs-automation[bot]]

[bad] Not working out of the box. I get an error that I reported here: #1450 (comment)

Forwarded from user feedback.

[fumadocs-automation[bot]]

[bad] ⨯ TypeError: this.getData is not a function
at new Promise ()
at processContent (app/llms.txt/route.ts:41:5)
at eval (app/llms.txt/route.ts:20:28)
at async GET (app/llms.txt/route.ts:27:18)
39 | // .use(your remark plugins)
40 | .use(remarkStringify) // to string

41 | .process(content);
| ^
42 |
43 | return String(file);
44 | }
GET /llms.txt 500 in 1269ms

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good]

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good]

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good] ımü

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good]

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good]

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good] good

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good]

Forwarded from user feedback.

[fumadocs-automation[bot]]

[bad]

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good]

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good]

Forwarded from user feedback.

[fumadocs-automation[bot]]

[bad] Hi, fuma-nama. First of all, I'd like to express my gratitude for your excellent work in building the documentation tool. Most of it is simple and easy to use, and the documentation is also very good. However, regarding the handling of LLM configuration redirection in this article, I think a more understandable approach could be adopted: directly making an API call instead of configuring the .mdx redirection. The core of the matter is that the client passes the .mdx document path parameter to the server, and the server parses the document according to the path and returns the result.

I encountered the 404 error multiple times when implementing the "Comy as Markdown" button. I also checked the original code related to the LLMCopyButton in your Github project, but still faced the 404 error several times. My project needs to support internationalization and requires middleware to handle some specific routes. As a result, the route rule matcher has issues with .mdx. Later, when I thought about the core of the above problem, I solved it by making a direct API call.

Forwarded from user feedback.

[caofanCPU]

[bad] Hi, fuma-nama. First of all, I'd like to express my gratitude for your excellent work in building the documentation tool. Most of it is simple and easy to use, and the documentation is also very good. However, regarding the handling of LLM configuration redirection in this article, I think a more understandable approach could be adopted: directly making an API call instead of configuring the .mdx redirection. The core of the matter is that the client passes the .mdx document path parameter to the server, and the server parses the document according to the path and returns the result.

I encountered the 404 error multiple times when implementing the "Comy as Markdown" button. I also checked the original code related to the LLMCopyButton in your Github project, but still faced the 404 error several times. My project needs to support internationalization and requires middleware to handle some specific routes. As a result, the route rule matcher has issues with .mdx. Later, when I thought about the core of the above problem, I solved it by making a direct API call.

Forwarded from user feedback.

My AI brother and I have discussed and summarized as follows:

Okay, let's summarize the advantages and disadvantages of the API routing method we just implemented and the .mdx rewrite method described in the Fumadocs official website documentation (https://fumadocs.dev/docs/ui/llms) in terms of obtaining LLM Markdown content.

Core objective: Both methods aim to enable the client (such as a copy button) to obtain the Markdown content on the current page that is suitable for LLM processing.

---

Method 1: .mdx Rewrite Method (Example from Fumadocs Official Website)

• Working mechanism:
  1. The client initiates a request by appending .mdx to the current page URL (e.g., /en/docs/page.mdx).
  2. The rewrites rules in next.config.ts capture this .mdx request.
  3. The rewrites rules internally redirect the request to a specific route handler (e.g., /app/[locale]/llms.mdx/[[...slug]]/route.ts) and pass the path parameters.
  4. The route handler retrieves the page data according to the parameters, generates the Markdown, and returns it.
• Advantages:
  • Simpler client-side logic potentially: Only need to append .mdx to the pathname.
  • Follows the official documentation: It is familiar to users who directly refer to this specific documentation.
• Disadvantages:
  • Complex and fragile configuration: It is necessary to write relatively complex rewrites rules in next.config.ts. These rules need to precisely match the path structure (including the locale in i18n), and it is easy to make mistakes.
  • Sensitive to middleware: It is extremely sensitive to the matcher configuration in middleware.ts. An incorrect matcher will cause the rewrites rules not to be executed at all, and the request will result in a 404 error directly, which is difficult to troubleshoot (we just experienced this).
  • Complex i18n handling: Correctly capturing and passing the locale in the rewrites rules will increase the complexity.
  • Lack of clarity: The association between the request initiation (appending .mdx) and the actual processing logic (a certain route.ts file) is not explicit, and one needs to check next.config.ts to understand it.
  • Lack of flexibility: If you want to change it to a POST request or pass more complex parameters, it will be very difficult or not elegant to implement through rewrites.
  • Difficult to debug: When problems occur (such as a 404 error), the problem may lie in multiple aspects, including client-side URL construction, middleware, rewrites rules, or the final route handler, which increases the difficulty of debugging.

---

Method 2: API Routing Method (The method we adopted)

• Working mechanism:
  1. The client obtains the locale and slug (path parameters) of the current page.
  2. The client initiates a request to a dedicated API endpoint (e.g., /api/llm-content) and passes the locale and path (concatenated from the slug) as query parameters (?locale=en&path=framework/page).
  3. A standard API route handler (/app/api/llm-content/route.ts) receives the request.
  4. The handler parses the query parameters, retrieves the page data, generates the Markdown, and returns it.
• Advantages:
  • Clear and standard: Using a dedicated API endpoint to obtain data is in line with the RESTful design principles and Next.js's standard practices.
  • Separation of concerns: The front end obtains the parameters and initiates the request, and the back-end API handles data retrieval and formatting, with a clear separation of logic.
  • Simple configuration: There is no need to add complex rewrites rules in next.config.ts for this function.
  • Less interference from middleware: API routes (/api/...) are usually excluded by the standard middleware matcher, or it is easy to configure the exclusion, reducing the possibility of conflicts.
  • Relatively easy to debug: The request process is straightforward: client -> API route -> response. It is easier to locate the problem.
  • Simple i18n handling: The locale is passed as an explicit query parameter, and the back-end processing is intuitive.
  • High flexibility:
    • It is easy to add or modify query parameters to pass more information.
    • If necessary, it is easy to change the GET request to a POST request and send more complex parameters or data in the request body without modifying the route configuration.
  • More robust: It is less likely to be accidentally interrupted due to minor changes in middleware or next.config.ts.
• Disadvantages:
  • Slightly more complex client-side logic: It is necessary to use useParams to obtain the route parameters and manually construct the query string URL.
  • Requires creating an additional API file: It is necessary to create a new /app/api/llm-content/route.ts file.
  • Different from the specific .mdx method on the official website: Although it achieves the same goal, the specific implementation method is different from the .mdx example in the Fumadocs LLM documentation.

---

Conclusion:

Although the .mdx rewrite method provided by the Fumadocs official website seems simple on the client side, in practical applications (especially in projects with i18n and custom middleware), it introduces significant configuration complexity and debugging difficulties, as evidenced by the 404 problem we encountered before.

The API routing method we finally adopted, although it adds a little more code for parameter acquisition and URL construction on the client side, is overall clearer, more robust, easier to maintain and debug, and more consistent with Next.js's standard practices. It also provides better flexibility to adapt to future changes (such as switching to a POST request). For solving the problems we encountered, this is obviously a more optimal choice.

[fumadocs-automation[bot]]

[bad] 组件呢

Forwarded from user feedback.

[fumadocs-automation[bot]]

[good] yep, good article

Forwarded from user feedback.

[fumadocs-automation[bot]]

[bad] no t

Forwarded from user feedback.

[fumadocs-automation[bot]]

[bad] not tall

Forwarded from user feedback.

[fumadocs-automation[bot]]

[bad] x

Forwarded from user feedback.

[fumadocs-automation[bot]]

[bad] I need full AI SDK implementation of this, not reliable enough.

Forwarded from user feedback.