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
I've been using the PDF docs in this repo as source of truth for LLMs to provide better coding assistance (currently using Cursor.sh).
Issue: I was not satisfied with the correctness of answers in relation to differentiating APIs for app/pages router. Even 4o and Claude 3.5 kept suggesting to use getStaticProps function for a project that uses the app router.
Source of problem: I was puzzled and wanted to get to the bottom of this. After I confirmed with the LLM that it has access to indexes of the entire codebase as well as the attached documentation referenced from your repo, I found that the PDF contains information for BOTH routers at the same time without any way to differentiate.
The official docs website is correct though, because it parses the MDX content with its JSX components embedded, like . This component is crucial to determine the correct information to display for a given router, and it's just iignored by regular markdown parsers.
Proposed solution: Generate the PDF docs in a way that takes into account the appearance of and components in the MDX files.
The text was updated successfully, but these errors were encountered:
I've been using the PDF docs in this repo as source of truth for LLMs to provide better coding assistance (currently using Cursor.sh).
Issue: I was not satisfied with the correctness of answers in relation to differentiating APIs for app/pages router. Even 4o and Claude 3.5 kept suggesting to use getStaticProps function for a project that uses the app router.
Source of problem: I was puzzled and wanted to get to the bottom of this. After I confirmed with the LLM that it has access to indexes of the entire codebase as well as the attached documentation referenced from your repo, I found that the PDF contains information for BOTH routers at the same time without any way to differentiate.
The official docs website is correct though, because it parses the MDX content with its JSX components embedded, like . This component is crucial to determine the correct information to display for a given router, and it's just iignored by regular markdown parsers.
Proposed solution: Generate the PDF docs in a way that takes into account the appearance of and components in the MDX files.
The text was updated successfully, but these errors were encountered: