Hi @crisp kayak. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
#turborepo packages
noble glenBOT
The decision to create new packages in a Turborepo depends on the structure and needs of your project. Turborepo is designed to handle monorepos, which are repositories that contain multiple packages or apps. This structure can be beneficial for code sharing and separation of concerns.
In the extracts provided, we see examples of Turborepo setups with various packages. For instance, the Turborepo Gatsby.js starter (https://vercel.com/templates/next.js/turborepo-gatsby-starter) includes packages for different apps (docs and web), a shared React component library (@repo/ui), and configurations (@repo/eslint-config and @repo/typescript-config). Similarly, the Turborepo Design System Starter (https://vercel.com/templates/react/turborepo-design-system) includes packages for component documentation (apps/docs), core React components (packages/ui), shared utilities (packages/utils), and shared TypeScript configurations (packages/typescript-config).
The packages you're considering (@org/react-framework-hooks, @org/react-framework-store, @org/react-framework-utils) seem to follow a similar pattern of separation. If these packages are intended to be used across multiple apps or components in your project, it could be beneficial to separate them. This can help with code organization, reusability, and testing.
However, it's also important to consider the overhead of managing multiple packages. If the packages are tightly coupled or don't have a clear separation of concerns, it might be more efficient to keep them together.
In conclusion, whether or not to create new packages depends on the specific needs and structure of your project. If the separation provides clear benefits in terms of code organization, reusability, and testing, it could be a good approach.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
noble glenBOT
Let me check the knowledge base for you. One moment! :books:
Creating multiple packages in a Turborepo is not necessarily "taking things too far". The decision should be based on the structure and needs of your project.
The main advantage of using a monorepo structure with multiple packages is that it allows for code sharing and separation of concerns. If the packages you're considering (@org/react-framework-hooks, @org/react-framework-store, @org/react-framework-utils) are intended to be used across multiple apps or components in your project, it could be beneficial to separate them. This can help with code organization, reusability, and testing.
However, it's also important to consider the overhead of managing multiple packages. If the packages are tightly coupled or don't have a clear separation of concerns, it might be more efficient to keep them together.
In conclusion, whether or not to create new packages depends on the specific needs and structure of your project. If the separation provides clear benefits in terms of code organization, reusability, and testing, it could be a good approach. But if the packages are tightly coupled, it might be better to keep them together.
Please note that the information provided is based on the general principles of organizing code in a monorepo and not specific to Turborepo or Next.js, as the provided extracts do not contain specific information about this topic.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
noble glenBOT
Let me check the knowledge base for you. One moment! :books:
Naming packages in a Turborepo, or any monorepo, should be done in a way that clearly communicates the package's purpose and scope. The names you're considering (@repo/utils, @repo/backend-utils, @repo/frontend-utils) seem to follow this principle.
@repo/utils: This could be a good name for a package that contains utilities shared across all parts of your project.@repo/backend-utils: This name suggests that the package contains utilities specifically for the backend part of your project.@repo/frontend-utils: Similarly, this name suggests that the package contains utilities specifically for the frontend.
This kind of naming convention can make it clear where certain code should go and where developers should look when they need to use or modify certain utilities. It also aligns with the examples given in the provided extracts, where packages are named according to their purpose (e.g., @repo/ui for a shared UI library, @repo/eslint-config for shared ESLint configurations).
However, it's also important to consider that splitting up your utilities into too many packages can potentially lead to more overhead in terms of package management. If your frontend and backend utilities have a lot of overlap, or if one or both of these packages are very small, it might be more efficient to keep them together in @repo/utils.
In conclusion, the proposed naming convention is not bad and can be beneficial for code organization and clarity. Whether or not to split up your utilities into separate frontend and backend packages depends on the specific needs and structure of your project.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
Let me check the knowledge base for you. One moment! :books:
You're correct that in the context of a React project, "hooks" are typically associated with the frontend. Therefore, naming a package @repo/frontend-hooks might be somewhat redundant.
If the hooks in this package are specifically for frontend use and you have other packages for backend or shared hooks, specifying "frontend" in the name could still be useful for clarity. However, if all your hooks are for frontend use, you could consider a simpler name like @repo/hooks.
Remember, the most important thing is that the package name clearly communicates its purpose and scope to everyone who works on the project. The exact naming convention you choose depends on the specific needs and structure of your project.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
noble glenBOT
Let me check the knowledge base for you. One moment! :books:
Based on the information provided in the extracts, it seems like your approach to conditional fetching with React Query is valid and aligns with common practices.
In the Next.js documentation, it's mentioned that you can use client-side data fetching at the component level, and the data is fetched at the time of the component mount. This is similar to what you're doing with your useUser hook, where you're only enabling the query if the user is authenticated.
The use of the enabled option in your query configuration is a common approach for conditional fetching with React Query. When enabled is false, the query will not automatically run. In your case, this prevents an unnecessary network request for user data when the user is not authenticated.
As for whether to use the useUser hook only in components that should be displayed when the user is authenticated, this depends on the specific needs of your application. If there are components that need to know about the user but should still be displayed even if the user is not authenticated, it could be beneficial to use the useUser hook in those components and handle the unauthenticated state appropriately.