Update README and refactor import path
Enhanced the README file with additional sections explaining import paths, non-route folders, server-side code, and updating packages. Additionally, the import path for 'UserAccountHeader' in the billing page file was refactored to a relative import for better readability and maintenance.
This commit is contained in:
18
README.md
18
README.md
@@ -231,11 +231,21 @@ Apps are used to define the main application, including the routing, layout, and
|
||||
|
||||
Apps pass down the configuration to the packages - and the packages provide the corresponding logic and components.
|
||||
|
||||
#### Imports and Paths
|
||||
|
||||
When importing something from a package or an app, you will use the following paths:
|
||||
|
||||
- When you import something from a package, you will use `@kit/package-name` (e.g., `@kit/ui`, `@kit/shared`, etc.).
|
||||
- When you import something from an app, you will use `~/` (e.g., `~/lib/components`, `~/config`, etc.).
|
||||
|
||||
#### Non-Route Folders
|
||||
|
||||
Non-route folders within `app` will be prefixed with an underscore (e.g., `_components`, `_lib`, etc.). This makes it obvious that these folders are not routes and are used for shared components, utilities, etc.
|
||||
|
||||
#### Server Code
|
||||
|
||||
The files localed in `server` folders are to be assumed as server-side code. They are not meant to be used in the client-side code. This helps everyone understanding where the code is meant to be run, since the lines are very blurry in Next.js.
|
||||
|
||||
### 2. Environment Variables
|
||||
|
||||
Environment variables are defined in the `.env` file in the root of the `apps/web` package.
|
||||
@@ -251,6 +261,14 @@ Your application will be defined in the `apps/web` package. This is where you wi
|
||||
|
||||
If you want - create a package for it - but it's not necessary. The `apps/web` package is the main application and you can place all your logic and files there.
|
||||
|
||||
### 4. Updating "packages"
|
||||
|
||||
The app is designed so that you should focus on what's in `apps/` and that's it. The packages are managed by the core team and are updated regularly.
|
||||
|
||||
So - should you update the packages? If you need to, then you need to.
|
||||
|
||||
Makerkit makes assumptions and as such - they may not apply to your specific use case. If you need to update the packages, you can and should do so - but it's worth noting that this will cause conflicts. That's fine, but you need to resolve them.
|
||||
|
||||
## Installing a Shadcn UI component
|
||||
|
||||
To install a Shadcn UI component, you can use the following command:
|
||||
|
||||
@@ -11,11 +11,11 @@ import { If } from '@kit/ui/if';
|
||||
import { PageBody } from '@kit/ui/page';
|
||||
import { Trans } from '@kit/ui/trans';
|
||||
|
||||
import { UserAccountHeader } from '~/(dashboard)/home/(user)/_components/user-account-header';
|
||||
import billingConfig from '~/config/billing.config';
|
||||
import { createI18nServerInstance } from '~/lib/i18n/i18n.server';
|
||||
import { withI18n } from '~/lib/i18n/with-i18n';
|
||||
|
||||
import { UserAccountHeader } from '../_components/user-account-header';
|
||||
import { createPersonalAccountBillingPortalSession } from '../billing/server-actions';
|
||||
import { PersonalAccountCheckoutForm } from './_components/personal-account-checkout-form';
|
||||
// user billing imports
|
||||
|
||||
Reference in New Issue
Block a user