2023-11-15 16:00:45 -05:00
|
|
|
{
|
|
|
|
|
"name": "@payloadcms/ui",
|
2025-11-25 13:37:17 -05:00
|
|
|
"version": "3.65.0",
|
2024-04-04 12:02:08 -04:00
|
|
|
"homepage": "https://payloadcms.com",
|
|
|
|
|
"repository": {
|
|
|
|
|
"type": "git",
|
|
|
|
|
"url": "https://github.com/payloadcms/payload.git",
|
|
|
|
|
"directory": "packages/ui"
|
|
|
|
|
},
|
2024-11-12 08:27:36 -07:00
|
|
|
"license": "MIT",
|
|
|
|
|
"author": "Payload <dev@payloadcms.com> (https://payloadcms.com)",
|
|
|
|
|
"maintainers": [
|
|
|
|
|
{
|
|
|
|
|
"name": "Payload",
|
|
|
|
|
"email": "info@payloadcms.com",
|
|
|
|
|
"url": "https://payloadcms.com"
|
|
|
|
|
}
|
|
|
|
|
],
|
2025-06-02 15:01:07 -07:00
|
|
|
"sideEffects": [
|
|
|
|
|
"*.scss",
|
|
|
|
|
"*.css"
|
|
|
|
|
],
|
2024-04-25 22:19:37 -04:00
|
|
|
"type": "module",
|
2023-11-15 17:22:40 -05:00
|
|
|
"exports": {
|
2024-06-19 12:36:00 -04:00
|
|
|
".": {
|
|
|
|
|
"import": "./src/exports/client/index.ts",
|
|
|
|
|
"types": "./src/exports/client/index.ts",
|
|
|
|
|
"default": "./src/exports/client/index.ts"
|
|
|
|
|
},
|
|
|
|
|
"./shared": {
|
|
|
|
|
"import": "./src/exports/shared/index.ts",
|
|
|
|
|
"types": "./src/exports/shared/index.ts",
|
|
|
|
|
"default": "./src/exports/shared/index.ts"
|
|
|
|
|
},
|
|
|
|
|
"./scss": {
|
|
|
|
|
"import": "./src/scss/styles.scss",
|
|
|
|
|
"default": "./src/scss/styles.scss"
|
feat!: prebundle payload, ui, richtext-lexical (#6579)
# Breaking Changes
### New file import locations
Exports from the `payload` package have been _significantly_ cleaned up.
Now, just about everything is able to be imported from `payload`
directly, rather than an assortment of subpath exports. This means that
things like `import { buildConfig } from 'payload/config'` are now just
imported via `import { buildConfig } from 'payload'`. The mental model
is significantly simpler for developers, but you might need to update
some of your imports.
Payload now exposes only three exports:
1. `payload` - all types and server-only Payload code
2. `payload/shared` - utilities that can be used in either the browser
or in Node environments
3. `payload/node` - heavy utilities that should only be imported in Node
scripts and never be imported into bundled code like Next.js
### UI library pre-bundling
With this release, we've dramatically sped up the compile time for
Payload by pre-bundling our entire UI package for use inside of the
Payload admin itself. There are new exports that should be used within
Payload custom components:
1. `@payloadcms/ui/client` - all client components
2. `@payloadcms/ui/server` - all server components
For all of your custom Payload admin UI components, you should be
importing from one of these two pre-compiled barrel files rather than
importing from the more deeply nested exports directly. That will keep
compile times nice and speedy, and will also make sure that the bundled
JS for your admin UI is kept small.
For example, whereas before, if you imported the Payload `Button`, you
would have imported it like this:
```ts
import { Button } from '@payloadcms/ui/elements/Button'
```
Now, you would import it like this:
```ts
import { Button } from '@payloadcms/ui/client'
```
This is a significant DX / performance optimization that we're pretty
pumped about.
However, if you are importing or re-using Payload UI components
_outside_ of the Payload admin UI, for example in your own frontend
apps, you can import from the individual component exports which will
make sure that the bundled JS is kept to a minimum in your frontend
apps. So in your own frontend, you can continue to import directly to
the components that you want to consume rather than importing from the
pre-compiled barrel files.
Individual component exports will now come with their corresponding CSS
and everything will work perfectly as-expected.
### Specific exports have changed
- `'@payloadcms/ui/templates/Default'` and
`'@payloadcms/ui/templates/Minimal`' are now exported from
`'@payloadcms/next/templates'`
- Old: `import { LogOut } from '@payloadcms/ui/icons/LogOut'` new:
`import { LogOutIcon } from '@payloadcms/ui/icons/LogOut'`
## Background info
In effort to make local dev as fast as possible, we need to import as
few files as possible so that the compiler has less to process. One way
we've achieved this in the Admin Panel was to _remove_ all .scss imports
from all components in the `@payloadcms/ui` module using a build
process. This stripped all `import './index.scss'` statements out of
each component before injecting them into `dist`. Instead, it bundles
all of the CSS into a single `main.css` file, and we import _that_ at
the root of the app.
While this concept is _still_ the right solution to the problem, this
particular approach is not viable when using these components outside
the Admin Panel, where not only does this root stylesheet not exist, but
where it would also bloat your app with unused styles. Instead, we need
to _keep_ these .scss imports in place so they are imported directly
alongside your components, as expected. Then, we need create a _new_
build step that _separately_ compiles the components _without_ their
stylesheets—this way your app can consume either as needed from the new
`client` and `server` barrel files within `@payloadcms/ui`, i.e. from
within `@payloadcms/next` and all other admin-specific packages and
plugins.
This way, all other applications will simply import using the direct
file paths, just as they did before. Except now they come with
stylesheets.
And we've gotten a pretty awesome initial compilation performance boost.
---------
Co-authored-by: James <james@trbl.design>
Co-authored-by: Alessio Gravili <alessio@gravili.de>
2024-06-17 14:25:36 -04:00
|
|
|
},
|
2025-06-26 10:55:28 -07:00
|
|
|
"./icons/*": {
|
|
|
|
|
"import": "./src/icons/*/index.tsx",
|
|
|
|
|
"types": "./src/icons/*/index.tsx",
|
|
|
|
|
"default": "./src/icons/*/index.tsx"
|
|
|
|
|
},
|
|
|
|
|
"./elements/*": {
|
|
|
|
|
"import": "./src/elements/*/index.tsx",
|
|
|
|
|
"types": "./src/elements/*/index.tsx",
|
|
|
|
|
"default": "./src/elements/*/index.tsx"
|
|
|
|
|
},
|
feat!: on demand rsc (#8364)
Currently, Payload renders all custom components on initial compile of
the admin panel. This is problematic for two key reasons:
1. Custom components do not receive contextual data, i.e. fields do not
receive their field data, edit views do not receive their document data,
etc.
2. Components are unnecessarily rendered before they are used
This was initially required to support React Server Components within
the Payload Admin Panel for two key reasons:
1. Fields can be dynamically rendered within arrays, blocks, etc.
2. Documents can be recursively rendered within a "drawer" UI, i.e.
relationship fields
3. Payload supports server/client component composition
In order to achieve this, components need to be rendered on the server
and passed as "slots" to the client. Currently, the pattern for this is
to render custom server components in the "client config". Then when a
view or field is needed to be rendered, we first check the client config
for a "pre-rendered" component, otherwise render our client-side
fallback component.
But for the reasons listed above, this pattern doesn't exactly make
custom server components very useful within the Payload Admin Panel,
which is where this PR comes in. Now, instead of pre-rendering all
components on initial compile, we're able to render custom components
_on demand_, only as they are needed.
To achieve this, we've established [this
pattern](https://github.com/payloadcms/payload/pull/8481) of React
Server Functions in the Payload Admin Panel. With Server Functions, we
can iterate the Payload Config and return JSX through React's
`text/x-component` content-type. This means we're able to pass
contextual props to custom components, such as data for fields and
views.
## Breaking Changes
1. Add the following to your root layout file, typically located at
`(app)/(payload)/layout.tsx`:
```diff
/* THIS FILE WAS GENERATED AUTOMATICALLY BY PAYLOAD. */
/* DO NOT MODIFY IT BECAUSE IT COULD BE REWRITTEN AT ANY TIME. */
+ import type { ServerFunctionClient } from 'payload'
import config from '@payload-config'
import { RootLayout } from '@payloadcms/next/layouts'
import { handleServerFunctions } from '@payloadcms/next/utilities'
import React from 'react'
import { importMap } from './admin/importMap.js'
import './custom.scss'
type Args = {
children: React.ReactNode
}
+ const serverFunctions: ServerFunctionClient = async function (args) {
+ 'use server'
+ return handleServerFunctions({
+ ...args,
+ config,
+ importMap,
+ })
+ }
const Layout = ({ children }: Args) => (
<RootLayout
config={config}
importMap={importMap}
+ serverFunctions={serverFunctions}
>
{children}
</RootLayout>
)
export default Layout
```
2. If you were previously posting to the `/api/form-state` endpoint, it
no longer exists. Instead, you'll need to invoke the `form-state` Server
Function, which can be done through the _new_ `getFormState` utility:
```diff
- import { getFormState } from '@payloadcms/ui'
- const { state } = await getFormState({
- apiRoute: '',
- body: {
- // ...
- },
- serverURL: ''
- })
+ const { getFormState } = useServerFunctions()
+
+ const { state } = await getFormState({
+ // ...
+ })
```
## Breaking Changes
```diff
- useFieldProps()
- useCellProps()
```
More details coming soon.
---------
Co-authored-by: Alessio Gravili <alessio@gravili.de>
Co-authored-by: Jarrod Flesch <jarrodmflesch@gmail.com>
Co-authored-by: James <james@trbl.design>
2024-11-11 13:59:05 -05:00
|
|
|
"./elements/RenderServerComponent": {
|
|
|
|
|
"import": "./src/elements/RenderServerComponent/index.tsx",
|
|
|
|
|
"types": "./src/elements/RenderServerComponent/index.tsx",
|
|
|
|
|
"default": "./src/elements/RenderServerComponent/index.tsx"
|
|
|
|
|
},
|
|
|
|
|
"./rsc": {
|
|
|
|
|
"import": "./src/exports/rsc/index.ts",
|
|
|
|
|
"types": "./src/exports/rsc/index.ts",
|
|
|
|
|
"default": "./src/exports/rsc/index.ts"
|
2024-03-19 15:23:22 -04:00
|
|
|
},
|
2024-06-19 14:16:31 -04:00
|
|
|
"./utilities/buildFormState": {
|
|
|
|
|
"import": "./src/utilities/buildFormState.ts",
|
|
|
|
|
"types": "./src/utilities/buildFormState.ts",
|
|
|
|
|
"default": "./src/utilities/buildFormState.ts"
|
2024-03-19 14:43:46 -04:00
|
|
|
},
|
feat!: on demand rsc (#8364)
Currently, Payload renders all custom components on initial compile of
the admin panel. This is problematic for two key reasons:
1. Custom components do not receive contextual data, i.e. fields do not
receive their field data, edit views do not receive their document data,
etc.
2. Components are unnecessarily rendered before they are used
This was initially required to support React Server Components within
the Payload Admin Panel for two key reasons:
1. Fields can be dynamically rendered within arrays, blocks, etc.
2. Documents can be recursively rendered within a "drawer" UI, i.e.
relationship fields
3. Payload supports server/client component composition
In order to achieve this, components need to be rendered on the server
and passed as "slots" to the client. Currently, the pattern for this is
to render custom server components in the "client config". Then when a
view or field is needed to be rendered, we first check the client config
for a "pre-rendered" component, otherwise render our client-side
fallback component.
But for the reasons listed above, this pattern doesn't exactly make
custom server components very useful within the Payload Admin Panel,
which is where this PR comes in. Now, instead of pre-rendering all
components on initial compile, we're able to render custom components
_on demand_, only as they are needed.
To achieve this, we've established [this
pattern](https://github.com/payloadcms/payload/pull/8481) of React
Server Functions in the Payload Admin Panel. With Server Functions, we
can iterate the Payload Config and return JSX through React's
`text/x-component` content-type. This means we're able to pass
contextual props to custom components, such as data for fields and
views.
## Breaking Changes
1. Add the following to your root layout file, typically located at
`(app)/(payload)/layout.tsx`:
```diff
/* THIS FILE WAS GENERATED AUTOMATICALLY BY PAYLOAD. */
/* DO NOT MODIFY IT BECAUSE IT COULD BE REWRITTEN AT ANY TIME. */
+ import type { ServerFunctionClient } from 'payload'
import config from '@payload-config'
import { RootLayout } from '@payloadcms/next/layouts'
import { handleServerFunctions } from '@payloadcms/next/utilities'
import React from 'react'
import { importMap } from './admin/importMap.js'
import './custom.scss'
type Args = {
children: React.ReactNode
}
+ const serverFunctions: ServerFunctionClient = async function (args) {
+ 'use server'
+ return handleServerFunctions({
+ ...args,
+ config,
+ importMap,
+ })
+ }
const Layout = ({ children }: Args) => (
<RootLayout
config={config}
importMap={importMap}
+ serverFunctions={serverFunctions}
>
{children}
</RootLayout>
)
export default Layout
```
2. If you were previously posting to the `/api/form-state` endpoint, it
no longer exists. Instead, you'll need to invoke the `form-state` Server
Function, which can be done through the _new_ `getFormState` utility:
```diff
- import { getFormState } from '@payloadcms/ui'
- const { state } = await getFormState({
- apiRoute: '',
- body: {
- // ...
- },
- serverURL: ''
- })
+ const { getFormState } = useServerFunctions()
+
+ const { state } = await getFormState({
+ // ...
+ })
```
## Breaking Changes
```diff
- useFieldProps()
- useCellProps()
```
More details coming soon.
---------
Co-authored-by: Alessio Gravili <alessio@gravili.de>
Co-authored-by: Jarrod Flesch <jarrodmflesch@gmail.com>
Co-authored-by: James <james@trbl.design>
2024-11-11 13:59:05 -05:00
|
|
|
"./utilities/buildTableState": {
|
|
|
|
|
"import": "./src/utilities/buildTableState.ts",
|
|
|
|
|
"types": "./src/utilities/buildTableState.ts",
|
|
|
|
|
"default": "./src/utilities/buildTableState.ts"
|
|
|
|
|
},
|
2025-06-10 11:56:28 -04:00
|
|
|
"./utilities/getFolderResultsComponentAndData": {
|
|
|
|
|
"import": "./src/utilities/getFolderResultsComponentAndData.tsx",
|
|
|
|
|
"types": "./src/utilities/getFolderResultsComponentAndData.tsx",
|
|
|
|
|
"default": "./src/utilities/getFolderResultsComponentAndData.tsx"
|
|
|
|
|
},
|
2025-01-28 15:17:24 -07:00
|
|
|
"./utilities/getClientSchemaMap": {
|
|
|
|
|
"import": "./src/utilities/getClientSchemaMap.ts",
|
|
|
|
|
"types": "./src/utilities/getClientSchemaMap.ts",
|
|
|
|
|
"default": "./src/utilities/getClientSchemaMap.ts"
|
|
|
|
|
},
|
|
|
|
|
"./utilities/getSchemaMap": {
|
|
|
|
|
"import": "./src/utilities/getSchemaMap.ts",
|
|
|
|
|
"types": "./src/utilities/getSchemaMap.ts",
|
|
|
|
|
"default": "./src/utilities/getSchemaMap.ts"
|
|
|
|
|
},
|
2024-12-27 16:52:18 -05:00
|
|
|
"./utilities/schedulePublishHandler": {
|
|
|
|
|
"import": "./src/utilities/schedulePublishHandler.ts",
|
|
|
|
|
"types": "./src/utilities/schedulePublishHandler.ts",
|
|
|
|
|
"default": "./src/utilities/schedulePublishHandler.ts"
|
|
|
|
|
},
|
perf: faster page navigation by speeding up createClientConfig, speed up version fetching, speed up lexical init. Up to 100x faster (#9457)
If you had a lot of fields and collections, createClientConfig would be
extremely slow, as it was copying a lot of memory. In my test config
with a lot of fields and collections, it took 4 seconds(!!).
And not only that, it also ran between every single page navigation.
This PR significantly speeds up the createClientConfig function. In my
test config, its execution speed went from 4 seconds to 50 ms.
Additionally, createClientConfig is now properly cached in both dev &
prod. It no longer runs between every single page navigation. Even if
you trigger a full page reload, createClientConfig will be cached and
not run again. Despite that, HMR remains fully-functional.
This will make payload feel noticeably faster for large configs -
especially if it contains a lot of richtext fields, as it was previously
deep-copying the relatively large richText editor configs over and over
again.
## Before - 40 sec navigation speed
https://github.com/user-attachments/assets/fe6b707a-459b-44c6-982a-b277f6cbb73f
## After - 1 sec navigation speed
https://github.com/user-attachments/assets/384fba63-dc32-4396-b3c2-0353fcac6639
## Todo
- [x] Implement ClientSchemaMap and cache it, to remove
createClientField call in our form state endpoint
- [x] Enable schemaMap caching for dev
- [x] Cache lexical clientField generation, or add it to the parent
clientConfig
## Lexical changes
Red: old / removed
Green: new
### Speed up version queries
This PR comes with performance optimizations for fetching versions
before a document is loaded. Not only does it use the new select API to
limit the fields it queries, it also completely skips a database query
if the current document is published.
### Speed up lexical init
Removes a bunch of unnecessary deep copying of lexical objects which
caused higher memory usage and slower load times. Additionally, the
lexical default config sanitization now happens less often.
2024-11-26 14:31:14 -07:00
|
|
|
"./utilities/getClientConfig": {
|
|
|
|
|
"import": "./src/utilities/getClientConfig.ts",
|
|
|
|
|
"types": "./src/utilities/getClientConfig.ts",
|
|
|
|
|
"default": "./src/utilities/getClientConfig.ts"
|
|
|
|
|
},
|
2024-06-19 14:16:31 -04:00
|
|
|
"./utilities/buildFieldSchemaMap/traverseFields": {
|
|
|
|
|
"import": "./src/utilities/buildFieldSchemaMap/traverseFields.ts",
|
|
|
|
|
"types": "./src/utilities/buildFieldSchemaMap/traverseFields.ts",
|
|
|
|
|
"default": "./src/utilities/buildFieldSchemaMap/traverseFields.ts"
|
2024-03-19 14:43:46 -04:00
|
|
|
},
|
feat!: on demand rsc (#8364)
Currently, Payload renders all custom components on initial compile of
the admin panel. This is problematic for two key reasons:
1. Custom components do not receive contextual data, i.e. fields do not
receive their field data, edit views do not receive their document data,
etc.
2. Components are unnecessarily rendered before they are used
This was initially required to support React Server Components within
the Payload Admin Panel for two key reasons:
1. Fields can be dynamically rendered within arrays, blocks, etc.
2. Documents can be recursively rendered within a "drawer" UI, i.e.
relationship fields
3. Payload supports server/client component composition
In order to achieve this, components need to be rendered on the server
and passed as "slots" to the client. Currently, the pattern for this is
to render custom server components in the "client config". Then when a
view or field is needed to be rendered, we first check the client config
for a "pre-rendered" component, otherwise render our client-side
fallback component.
But for the reasons listed above, this pattern doesn't exactly make
custom server components very useful within the Payload Admin Panel,
which is where this PR comes in. Now, instead of pre-rendering all
components on initial compile, we're able to render custom components
_on demand_, only as they are needed.
To achieve this, we've established [this
pattern](https://github.com/payloadcms/payload/pull/8481) of React
Server Functions in the Payload Admin Panel. With Server Functions, we
can iterate the Payload Config and return JSX through React's
`text/x-component` content-type. This means we're able to pass
contextual props to custom components, such as data for fields and
views.
## Breaking Changes
1. Add the following to your root layout file, typically located at
`(app)/(payload)/layout.tsx`:
```diff
/* THIS FILE WAS GENERATED AUTOMATICALLY BY PAYLOAD. */
/* DO NOT MODIFY IT BECAUSE IT COULD BE REWRITTEN AT ANY TIME. */
+ import type { ServerFunctionClient } from 'payload'
import config from '@payload-config'
import { RootLayout } from '@payloadcms/next/layouts'
import { handleServerFunctions } from '@payloadcms/next/utilities'
import React from 'react'
import { importMap } from './admin/importMap.js'
import './custom.scss'
type Args = {
children: React.ReactNode
}
+ const serverFunctions: ServerFunctionClient = async function (args) {
+ 'use server'
+ return handleServerFunctions({
+ ...args,
+ config,
+ importMap,
+ })
+ }
const Layout = ({ children }: Args) => (
<RootLayout
config={config}
importMap={importMap}
+ serverFunctions={serverFunctions}
>
{children}
</RootLayout>
)
export default Layout
```
2. If you were previously posting to the `/api/form-state` endpoint, it
no longer exists. Instead, you'll need to invoke the `form-state` Server
Function, which can be done through the _new_ `getFormState` utility:
```diff
- import { getFormState } from '@payloadcms/ui'
- const { state } = await getFormState({
- apiRoute: '',
- body: {
- // ...
- },
- serverURL: ''
- })
+ const { getFormState } = useServerFunctions()
+
+ const { state } = await getFormState({
+ // ...
+ })
```
## Breaking Changes
```diff
- useFieldProps()
- useCellProps()
```
More details coming soon.
---------
Co-authored-by: Alessio Gravili <alessio@gravili.de>
Co-authored-by: Jarrod Flesch <jarrodmflesch@gmail.com>
Co-authored-by: James <james@trbl.design>
2024-11-11 13:59:05 -05:00
|
|
|
"./forms/fieldSchemasToFormState": {
|
|
|
|
|
"import": "./src/forms/fieldSchemasToFormState/index.tsx",
|
|
|
|
|
"types": "./src/forms/fieldSchemasToFormState/index.tsx",
|
|
|
|
|
"default": "./src/forms/fieldSchemasToFormState/index.tsx"
|
2024-03-19 14:43:46 -04:00
|
|
|
},
|
perf(richtext-lexical)!: significantly reduce lexical rerendering and amount of network requests from blocks (#9255)
The field RSC now provides an initial state for all lexical blocks. This
completely obliterates any flashes and lexical block loading states when
loading or saving a document.
Previously, when a document is loaded or saved, every lexical block was
sending a network request in order to fetch their form state. Now, this
is batched and handled in the lexical server component. All lexical
block form states are sent to the client together with the parent
lexical field, and are thus available immediately.
We also do the same with block collapsed preferences. Thus, there are no
loading states or layout shifts/flashes of blocks anymore.
Additionally, when saving a document while your cursor is inside a
lexical field, the cursor position is preserved. Previously, a document
save would kick your cursor out of the lexical field.
## Look at how nice this is:
https://github.com/user-attachments/assets/21d736d4-8f80-4df0-a782-7509edd993da
**BREAKING:**
This removes the `feature.hooks.load` and `feature.hooks.save`
interfaces from custom lexical features, as they weren't used internally
and added unnecessary, additional overhead.
If you have custom features that use those, you can migrate to using
normal payload hooks that run on the server instead of the client.
2024-11-17 01:31:55 -07:00
|
|
|
"./forms/renderField": {
|
|
|
|
|
"import": "./src/forms/fieldSchemasToFormState/renderField.tsx",
|
|
|
|
|
"types": "./src/forms/fieldSchemasToFormState/renderField.tsx",
|
|
|
|
|
"default": "./src/forms/fieldSchemasToFormState/renderField.tsx"
|
|
|
|
|
},
|
2024-06-19 14:16:31 -04:00
|
|
|
"./scss/app.scss": "./src/scss/app.scss",
|
|
|
|
|
"./assets": {
|
|
|
|
|
"import": "./src/assets/index.ts",
|
|
|
|
|
"types": "./src/assets/index.ts",
|
|
|
|
|
"default": "./src/assets/index.ts"
|
2024-06-19 12:36:00 -04:00
|
|
|
}
|
2024-03-04 11:32:57 -05:00
|
|
|
},
|
2024-06-19 12:36:00 -04:00
|
|
|
"main": "./src/exports/client/index.ts",
|
|
|
|
|
"types": "./src/exports/client/index.ts",
|
2024-04-25 22:19:37 -04:00
|
|
|
"files": [
|
|
|
|
|
"dist"
|
|
|
|
|
],
|
|
|
|
|
"scripts": {
|
2024-08-19 17:31:36 -04:00
|
|
|
"build": "pnpm build:reactcompiler",
|
|
|
|
|
"build:babel": "rm -rf dist_optimized && babel dist --out-dir dist_optimized --source-maps --extensions .ts,.js,.tsx,.jsx,.cjs,.mjs && rm -rf dist && mv dist_optimized dist",
|
2025-07-07 13:00:02 -07:00
|
|
|
"build:bundle-for-analysis": "rm -rf dist && rm -rf tsconfig.tsbuildinfo && pnpm build:swc && pnpm build:babel && pnpm copyfiles && pnpm build:esbuild esbuild --no-split",
|
|
|
|
|
"build:esbuild": "node bundle.js",
|
|
|
|
|
"build:esbuild:postprocess": "rm -rf dist/exports/client && mv dist/exports/client_optimized dist/exports/client && rm -rf dist/exports/shared && mv dist/exports/shared_optimized dist/exports/shared",
|
|
|
|
|
"build:reactcompiler": "rm -rf dist esbuild && rm -rf tsconfig.tsbuildinfo && pnpm build:swc && pnpm build:babel && pnpm copyfiles && pnpm build:esbuild && pnpm build:esbuild:postprocess && pnpm build:types",
|
2024-04-25 22:19:37 -04:00
|
|
|
"build:remove-artifact": "rm dist/prod/index.js",
|
feat!: prebundle payload, ui, richtext-lexical (#6579)
# Breaking Changes
### New file import locations
Exports from the `payload` package have been _significantly_ cleaned up.
Now, just about everything is able to be imported from `payload`
directly, rather than an assortment of subpath exports. This means that
things like `import { buildConfig } from 'payload/config'` are now just
imported via `import { buildConfig } from 'payload'`. The mental model
is significantly simpler for developers, but you might need to update
some of your imports.
Payload now exposes only three exports:
1. `payload` - all types and server-only Payload code
2. `payload/shared` - utilities that can be used in either the browser
or in Node environments
3. `payload/node` - heavy utilities that should only be imported in Node
scripts and never be imported into bundled code like Next.js
### UI library pre-bundling
With this release, we've dramatically sped up the compile time for
Payload by pre-bundling our entire UI package for use inside of the
Payload admin itself. There are new exports that should be used within
Payload custom components:
1. `@payloadcms/ui/client` - all client components
2. `@payloadcms/ui/server` - all server components
For all of your custom Payload admin UI components, you should be
importing from one of these two pre-compiled barrel files rather than
importing from the more deeply nested exports directly. That will keep
compile times nice and speedy, and will also make sure that the bundled
JS for your admin UI is kept small.
For example, whereas before, if you imported the Payload `Button`, you
would have imported it like this:
```ts
import { Button } from '@payloadcms/ui/elements/Button'
```
Now, you would import it like this:
```ts
import { Button } from '@payloadcms/ui/client'
```
This is a significant DX / performance optimization that we're pretty
pumped about.
However, if you are importing or re-using Payload UI components
_outside_ of the Payload admin UI, for example in your own frontend
apps, you can import from the individual component exports which will
make sure that the bundled JS is kept to a minimum in your frontend
apps. So in your own frontend, you can continue to import directly to
the components that you want to consume rather than importing from the
pre-compiled barrel files.
Individual component exports will now come with their corresponding CSS
and everything will work perfectly as-expected.
### Specific exports have changed
- `'@payloadcms/ui/templates/Default'` and
`'@payloadcms/ui/templates/Minimal`' are now exported from
`'@payloadcms/next/templates'`
- Old: `import { LogOut } from '@payloadcms/ui/icons/LogOut'` new:
`import { LogOutIcon } from '@payloadcms/ui/icons/LogOut'`
## Background info
In effort to make local dev as fast as possible, we need to import as
few files as possible so that the compiler has less to process. One way
we've achieved this in the Admin Panel was to _remove_ all .scss imports
from all components in the `@payloadcms/ui` module using a build
process. This stripped all `import './index.scss'` statements out of
each component before injecting them into `dist`. Instead, it bundles
all of the CSS into a single `main.css` file, and we import _that_ at
the root of the app.
While this concept is _still_ the right solution to the problem, this
particular approach is not viable when using these components outside
the Admin Panel, where not only does this root stylesheet not exist, but
where it would also bloat your app with unused styles. Instead, we need
to _keep_ these .scss imports in place so they are imported directly
alongside your components, as expected. Then, we need create a _new_
build step that _separately_ compiles the components _without_ their
stylesheets—this way your app can consume either as needed from the new
`client` and `server` barrel files within `@payloadcms/ui`, i.e. from
within `@payloadcms/next` and all other admin-specific packages and
plugins.
This way, all other applications will simply import using the direct
file paths, just as they did before. Except now they come with
stylesheets.
And we've gotten a pretty awesome initial compilation performance boost.
---------
Co-authored-by: James <james@trbl.design>
Co-authored-by: Alessio Gravili <alessio@gravili.de>
2024-06-17 14:25:36 -04:00
|
|
|
"build:swc": "swc ./src -d dist --config-file .swcrc --strip-leading-paths",
|
2024-04-25 22:19:37 -04:00
|
|
|
"build:types": "tsc --emitDeclarationOnly --outDir dist",
|
2024-08-23 14:01:21 -04:00
|
|
|
"build:without_reactcompiler": "rm -rf dist && rm -rf tsconfig.tsbuildinfo && pnpm copyfiles && pnpm build:types && pnpm build:swc",
|
2025-10-01 10:56:12 -04:00
|
|
|
"clean": "rimraf -g {dist,*.tsbuildinfo,esbuild}",
|
2024-04-25 22:19:37 -04:00
|
|
|
"copyfiles": "copyfiles -u 1 \"src/**/*.{html,css,scss,ttf,woff,woff2,eot,svg,jpg,png,json}\" dist/",
|
2024-08-28 21:55:34 -04:00
|
|
|
"lint": "eslint .",
|
|
|
|
|
"lint:fix": "eslint . --fix",
|
2024-04-25 22:19:37 -04:00
|
|
|
"prepublishOnly": "pnpm clean && pnpm turbo build"
|
|
|
|
|
},
|
|
|
|
|
"dependencies": {
|
feat: add timezone support on date fields (#10896)
Adds support for timezone selection on date fields.
### Summary
New `admin.timezones` config:
```ts
{
// ...
admin: {
// ...
timezones: {
supportedTimezones: ({ defaultTimezones }) => [
...defaultTimezones,
{ label: '(GMT-6) Monterrey, Nuevo Leon', value: 'America/Monterrey' },
],
defaultTimezone: 'America/Monterrey',
},
}
}
```
New `timezone` property on date fields:
```ts
{
type: 'date',
name: 'date',
timezone: true,
}
```
### Configuration
All date fields now accept `timezone: true` to enable this feature,
which will inject a new field into the configuration using the date
field's name to construct the name for the timezone column. So
`publishingDate` will have `publishingDate_tz` as an accompanying
column. This new field is inserted during config sanitisation.
Dates continue to be stored in UTC, this will help maintain dates
without needing a migration and it makes it easier for data to be
manipulated as needed. Mongodb also has a restriction around storing
dates only as UTC.
All timezones are stored by their IANA names so it's compatible with
browser APIs. There is a newly generated type for `SupportedTimezones`
which is reused across fields.
We handle timezone calculations via a new package `@date-fns/tz` which
we will be using in the future for handling timezone aware scheduled
publishing/unpublishing and more.
### UI
Dark mode
Light mode
2025-02-10 20:02:53 +00:00
|
|
|
"@date-fns/tz": "1.2.0",
|
2024-04-25 22:19:37 -04:00
|
|
|
"@dnd-kit/core": "6.0.8",
|
|
|
|
|
"@dnd-kit/sortable": "7.0.2",
|
2025-05-22 10:04:45 -04:00
|
|
|
"@dnd-kit/utilities": "3.2.2",
|
2025-09-17 11:51:11 -04:00
|
|
|
"@faceless-ui/modal": "3.0.0",
|
2025-01-31 12:39:04 -05:00
|
|
|
"@faceless-ui/scroll-info": "2.0.0",
|
|
|
|
|
"@faceless-ui/window-info": "3.0.1",
|
2025-02-13 12:24:53 -05:00
|
|
|
"@monaco-editor/react": "4.7.0",
|
2024-04-25 22:19:37 -04:00
|
|
|
"@payloadcms/translations": "workspace:*",
|
|
|
|
|
"bson-objectid": "2.0.4",
|
2024-11-15 14:36:14 -05:00
|
|
|
"date-fns": "4.1.0",
|
2024-06-25 09:40:16 -04:00
|
|
|
"dequal": "2.0.3",
|
2024-04-25 22:19:37 -04:00
|
|
|
"md5": "2.3.0",
|
|
|
|
|
"object-to-formdata": "4.5.1",
|
2024-07-09 10:33:38 -04:00
|
|
|
"qs-esm": "7.0.2",
|
2025-01-05 19:21:53 -05:00
|
|
|
"react-datepicker": "7.6.0",
|
2024-04-25 22:19:37 -04:00
|
|
|
"react-image-crop": "10.1.8",
|
2024-12-13 15:25:21 -05:00
|
|
|
"react-select": "5.9.0",
|
2024-12-06 12:53:36 -07:00
|
|
|
"scheduler": "0.25.0",
|
2025-01-17 12:00:14 -06:00
|
|
|
"sonner": "^1.7.2",
|
2024-11-07 15:54:45 -07:00
|
|
|
"ts-essentials": "10.0.3",
|
2024-06-03 17:23:05 -04:00
|
|
|
"use-context-selector": "2.0.0",
|
feat!: prebundle payload, ui, richtext-lexical (#6579)
# Breaking Changes
### New file import locations
Exports from the `payload` package have been _significantly_ cleaned up.
Now, just about everything is able to be imported from `payload`
directly, rather than an assortment of subpath exports. This means that
things like `import { buildConfig } from 'payload/config'` are now just
imported via `import { buildConfig } from 'payload'`. The mental model
is significantly simpler for developers, but you might need to update
some of your imports.
Payload now exposes only three exports:
1. `payload` - all types and server-only Payload code
2. `payload/shared` - utilities that can be used in either the browser
or in Node environments
3. `payload/node` - heavy utilities that should only be imported in Node
scripts and never be imported into bundled code like Next.js
### UI library pre-bundling
With this release, we've dramatically sped up the compile time for
Payload by pre-bundling our entire UI package for use inside of the
Payload admin itself. There are new exports that should be used within
Payload custom components:
1. `@payloadcms/ui/client` - all client components
2. `@payloadcms/ui/server` - all server components
For all of your custom Payload admin UI components, you should be
importing from one of these two pre-compiled barrel files rather than
importing from the more deeply nested exports directly. That will keep
compile times nice and speedy, and will also make sure that the bundled
JS for your admin UI is kept small.
For example, whereas before, if you imported the Payload `Button`, you
would have imported it like this:
```ts
import { Button } from '@payloadcms/ui/elements/Button'
```
Now, you would import it like this:
```ts
import { Button } from '@payloadcms/ui/client'
```
This is a significant DX / performance optimization that we're pretty
pumped about.
However, if you are importing or re-using Payload UI components
_outside_ of the Payload admin UI, for example in your own frontend
apps, you can import from the individual component exports which will
make sure that the bundled JS is kept to a minimum in your frontend
apps. So in your own frontend, you can continue to import directly to
the components that you want to consume rather than importing from the
pre-compiled barrel files.
Individual component exports will now come with their corresponding CSS
and everything will work perfectly as-expected.
### Specific exports have changed
- `'@payloadcms/ui/templates/Default'` and
`'@payloadcms/ui/templates/Minimal`' are now exported from
`'@payloadcms/next/templates'`
- Old: `import { LogOut } from '@payloadcms/ui/icons/LogOut'` new:
`import { LogOutIcon } from '@payloadcms/ui/icons/LogOut'`
## Background info
In effort to make local dev as fast as possible, we need to import as
few files as possible so that the compiler has less to process. One way
we've achieved this in the Admin Panel was to _remove_ all .scss imports
from all components in the `@payloadcms/ui` module using a build
process. This stripped all `import './index.scss'` statements out of
each component before injecting them into `dist`. Instead, it bundles
all of the CSS into a single `main.css` file, and we import _that_ at
the root of the app.
While this concept is _still_ the right solution to the problem, this
particular approach is not viable when using these components outside
the Admin Panel, where not only does this root stylesheet not exist, but
where it would also bloat your app with unused styles. Instead, we need
to _keep_ these .scss imports in place so they are imported directly
alongside your components, as expected. Then, we need create a _new_
build step that _separately_ compiles the components _without_ their
stylesheets—this way your app can consume either as needed from the new
`client` and `server` barrel files within `@payloadcms/ui`, i.e. from
within `@payloadcms/next` and all other admin-specific packages and
plugins.
This way, all other applications will simply import using the direct
file paths, just as they did before. Except now they come with
stylesheets.
And we've gotten a pretty awesome initial compilation performance boost.
---------
Co-authored-by: James <james@trbl.design>
Co-authored-by: Alessio Gravili <alessio@gravili.de>
2024-06-17 14:25:36 -04:00
|
|
|
"uuid": "10.0.0"
|
2024-04-25 22:19:37 -04:00
|
|
|
},
|
|
|
|
|
"devDependencies": {
|
2025-06-02 15:01:07 -07:00
|
|
|
"@babel/cli": "7.27.2",
|
|
|
|
|
"@babel/core": "7.27.3",
|
|
|
|
|
"@babel/preset-env": "7.27.2",
|
|
|
|
|
"@babel/preset-react": "7.27.1",
|
|
|
|
|
"@babel/preset-typescript": "7.27.1",
|
|
|
|
|
"@hyrious/esbuild-plugin-commonjs": "0.2.6",
|
2024-04-25 22:19:37 -04:00
|
|
|
"@payloadcms/eslint-config": "workspace:*",
|
feat(richtext-lexical): utility render lexical field on-demand (#13657)
## Why this exists
Lexical in Payload is a React Server Component (RSC). Historically that
created three headaches:
1. You couldn’t render the editor directly from the client.
2. Features like blocks, tables, upload and link drawers require the
server to know the shape of nested sub‑fields at render time. If you
tried to render on demand, the server didn’t know those schemas.
3. The rich text field is designed to live inside a Form. For simple use
cases, setting up a full form just to manage editor state was
cumbersome.
## What’s new
We now ship a client component, `<RenderLexical />`, that renders a
Lexical editor **on demand** while still covering the full feature set.
On mount, it calls a server action to render the editor on the server
using the new `render-field` server action. That server render gives
Lexical everything it needs (including nested field schemas) and returns
a ready‑to‑hydrate editor.
## Example - Rendering in custom component within existing Form
```tsx
'use client'
import type { JSONFieldClientComponent } from 'payload'
import { buildEditorState, RenderLexical } from '@payloadcms/richtext-lexical/client'
import { lexicalFullyFeaturedSlug } from '../../slugs.js'
export const Component: JSONFieldClientComponent = (args) => {
return (
<div>
Fully-Featured Component:
<RenderLexical
field={{ name: 'json' }}
initialValue={buildEditorState({ text: 'defaultValue' })}
schemaPath={`collection.${lexicalFullyFeaturedSlug}.richText`}
/>
</div>
)
}
```
## Example - Rendering outside of Form, manually managing richText
values
```ts
'use client'
import type { DefaultTypedEditorState } from '@payloadcms/richtext-lexical'
import type { JSONFieldClientComponent } from 'payload'
import { buildEditorState, RenderLexical } from '@payloadcms/richtext-lexical/client'
import React, { useState } from 'react'
import { lexicalFullyFeaturedSlug } from '../../slugs.js'
export const Component: JSONFieldClientComponent = (args) => {
const [value, setValue] = useState<DefaultTypedEditorState | undefined>(() =>
buildEditorState({ text: 'state default' }),
)
const handleReset = React.useCallback(() => {
setValue(buildEditorState({ text: 'state default' }))
}, [])
return (
<div>
Default Component:
<RenderLexical
field={{ name: 'json' }}
initialValue={buildEditorState({ text: 'defaultValue' })}
schemaPath={`collection.${lexicalFullyFeaturedSlug}.richText`}
setValue={setValue as any}
value={value}
/>
<button onClick={handleReset} style={{ marginTop: 8 }} type="button">
Reset Editor State
</button>
</div>
)
}
```
## How it works (under the hood)
- On first render, `<RenderLexical />` calls the server function
`render-field` (wired into @payloadcms/next), passing a schemaPath.
- The server loads the exact field config and its client schema map for
that path, renders the Lexical editor server‑side (so nested features
like blocks/tables/relationships are fully known), and returns the
component tree.
- While waiting, the client shows a small shimmer skeleton.
- Inside Forms, RenderLexical plugs into the parent form via useField;
outside Forms, you can fully control the value by passing
value/setValue.
## Type Improvements
While implementing the `buildEditorState` helper function for our test
suite, I noticed some issues with our `TypedEditorState` type:
- nodes were no longer narrowed by their node.type types
- upon fixing this issue, the type was no longer compatible with the
generated types. To address this, I had to weaken the generated type a
bit.
In order to ensure the type will keep functioning as intended from now
on, this PR also adds some type tests
---
- To see the specific tasks where the Asana app for GitHub is being
used, see below:
- https://app.asana.com/0/0/1211110462564644
2025-09-18 15:01:12 -07:00
|
|
|
"@types/react": "19.1.12",
|
|
|
|
|
"@types/react-dom": "19.1.9",
|
2024-07-06 00:08:29 -04:00
|
|
|
"@types/uuid": "10.0.0",
|
feat(richtext-lexical): utility render lexical field on-demand (#13657)
## Why this exists
Lexical in Payload is a React Server Component (RSC). Historically that
created three headaches:
1. You couldn’t render the editor directly from the client.
2. Features like blocks, tables, upload and link drawers require the
server to know the shape of nested sub‑fields at render time. If you
tried to render on demand, the server didn’t know those schemas.
3. The rich text field is designed to live inside a Form. For simple use
cases, setting up a full form just to manage editor state was
cumbersome.
## What’s new
We now ship a client component, `<RenderLexical />`, that renders a
Lexical editor **on demand** while still covering the full feature set.
On mount, it calls a server action to render the editor on the server
using the new `render-field` server action. That server render gives
Lexical everything it needs (including nested field schemas) and returns
a ready‑to‑hydrate editor.
## Example - Rendering in custom component within existing Form
```tsx
'use client'
import type { JSONFieldClientComponent } from 'payload'
import { buildEditorState, RenderLexical } from '@payloadcms/richtext-lexical/client'
import { lexicalFullyFeaturedSlug } from '../../slugs.js'
export const Component: JSONFieldClientComponent = (args) => {
return (
<div>
Fully-Featured Component:
<RenderLexical
field={{ name: 'json' }}
initialValue={buildEditorState({ text: 'defaultValue' })}
schemaPath={`collection.${lexicalFullyFeaturedSlug}.richText`}
/>
</div>
)
}
```
## Example - Rendering outside of Form, manually managing richText
values
```ts
'use client'
import type { DefaultTypedEditorState } from '@payloadcms/richtext-lexical'
import type { JSONFieldClientComponent } from 'payload'
import { buildEditorState, RenderLexical } from '@payloadcms/richtext-lexical/client'
import React, { useState } from 'react'
import { lexicalFullyFeaturedSlug } from '../../slugs.js'
export const Component: JSONFieldClientComponent = (args) => {
const [value, setValue] = useState<DefaultTypedEditorState | undefined>(() =>
buildEditorState({ text: 'state default' }),
)
const handleReset = React.useCallback(() => {
setValue(buildEditorState({ text: 'state default' }))
}, [])
return (
<div>
Default Component:
<RenderLexical
field={{ name: 'json' }}
initialValue={buildEditorState({ text: 'defaultValue' })}
schemaPath={`collection.${lexicalFullyFeaturedSlug}.richText`}
setValue={setValue as any}
value={value}
/>
<button onClick={handleReset} style={{ marginTop: 8 }} type="button">
Reset Editor State
</button>
</div>
)
}
```
## How it works (under the hood)
- On first render, `<RenderLexical />` calls the server function
`render-field` (wired into @payloadcms/next), passing a schemaPath.
- The server loads the exact field config and its client schema map for
that path, renders the Lexical editor server‑side (so nested features
like blocks/tables/relationships are fully known), and returns the
component tree.
- While waiting, the client shows a small shimmer skeleton.
- Inside Forms, RenderLexical plugs into the parent form via useField;
outside Forms, you can fully control the value by passing
value/setValue.
## Type Improvements
While implementing the `buildEditorState` helper function for our test
suite, I noticed some issues with our `TypedEditorState` type:
- nodes were no longer narrowed by their node.type types
- upon fixing this issue, the type was no longer compatible with the
generated types. To address this, I had to weaken the generated type a
bit.
In order to ensure the type will keep functioning as intended from now
on, this PR also adds some type tests
---
- To see the specific tasks where the Asana app for GitHub is being
used, see below:
- https://app.asana.com/0/0/1211110462564644
2025-09-18 15:01:12 -07:00
|
|
|
"babel-plugin-react-compiler": "19.1.0-rc.3",
|
2025-06-02 15:01:07 -07:00
|
|
|
"esbuild": "0.25.5",
|
2024-07-11 14:33:45 -04:00
|
|
|
"esbuild-sass-plugin": "3.3.1",
|
|
|
|
|
"payload": "workspace:*"
|
2024-04-25 22:19:37 -04:00
|
|
|
},
|
|
|
|
|
"peerDependencies": {
|
2025-03-24 07:41:33 -06:00
|
|
|
"next": "^15.2.3",
|
2024-04-25 22:19:37 -04:00
|
|
|
"payload": "workspace:*",
|
2024-10-21 23:12:22 -04:00
|
|
|
"react": "^19.0.0 || ^19.0.0-rc-65a56d0e-20241020",
|
|
|
|
|
"react-dom": "^19.0.0 || ^19.0.0-rc-65a56d0e-20241020"
|
2024-04-25 22:19:37 -04:00
|
|
|
},
|
|
|
|
|
"engines": {
|
2024-06-06 13:15:21 -04:00
|
|
|
"node": "^18.20.2 || >=20.9.0"
|
2024-04-25 22:19:37 -04:00
|
|
|
},
|
2024-03-04 11:32:57 -05:00
|
|
|
"publishConfig": {
|
|
|
|
|
"exports": {
|
2024-06-19 12:36:00 -04:00
|
|
|
".": {
|
|
|
|
|
"import": "./dist/exports/client/index.js",
|
|
|
|
|
"types": "./dist/exports/client/index.d.ts",
|
|
|
|
|
"default": "./dist/exports/client/index.js"
|
|
|
|
|
},
|
|
|
|
|
"./shared": {
|
|
|
|
|
"import": "./dist/exports/shared/index.js",
|
|
|
|
|
"types": "./dist/exports/shared/index.d.ts",
|
|
|
|
|
"default": "./dist/exports/shared/index.js"
|
|
|
|
|
},
|
|
|
|
|
"./css": {
|
2024-08-19 17:31:36 -04:00
|
|
|
"import": "./dist/styles.css",
|
|
|
|
|
"default": "./dist/styles.css"
|
2024-06-19 12:36:00 -04:00
|
|
|
},
|
|
|
|
|
"./scss": {
|
|
|
|
|
"import": "./dist/scss/styles.scss",
|
|
|
|
|
"default": "./dist/scss/styles.scss"
|
|
|
|
|
},
|
feat!: on demand rsc (#8364)
Currently, Payload renders all custom components on initial compile of
the admin panel. This is problematic for two key reasons:
1. Custom components do not receive contextual data, i.e. fields do not
receive their field data, edit views do not receive their document data,
etc.
2. Components are unnecessarily rendered before they are used
This was initially required to support React Server Components within
the Payload Admin Panel for two key reasons:
1. Fields can be dynamically rendered within arrays, blocks, etc.
2. Documents can be recursively rendered within a "drawer" UI, i.e.
relationship fields
3. Payload supports server/client component composition
In order to achieve this, components need to be rendered on the server
and passed as "slots" to the client. Currently, the pattern for this is
to render custom server components in the "client config". Then when a
view or field is needed to be rendered, we first check the client config
for a "pre-rendered" component, otherwise render our client-side
fallback component.
But for the reasons listed above, this pattern doesn't exactly make
custom server components very useful within the Payload Admin Panel,
which is where this PR comes in. Now, instead of pre-rendering all
components on initial compile, we're able to render custom components
_on demand_, only as they are needed.
To achieve this, we've established [this
pattern](https://github.com/payloadcms/payload/pull/8481) of React
Server Functions in the Payload Admin Panel. With Server Functions, we
can iterate the Payload Config and return JSX through React's
`text/x-component` content-type. This means we're able to pass
contextual props to custom components, such as data for fields and
views.
## Breaking Changes
1. Add the following to your root layout file, typically located at
`(app)/(payload)/layout.tsx`:
```diff
/* THIS FILE WAS GENERATED AUTOMATICALLY BY PAYLOAD. */
/* DO NOT MODIFY IT BECAUSE IT COULD BE REWRITTEN AT ANY TIME. */
+ import type { ServerFunctionClient } from 'payload'
import config from '@payload-config'
import { RootLayout } from '@payloadcms/next/layouts'
import { handleServerFunctions } from '@payloadcms/next/utilities'
import React from 'react'
import { importMap } from './admin/importMap.js'
import './custom.scss'
type Args = {
children: React.ReactNode
}
+ const serverFunctions: ServerFunctionClient = async function (args) {
+ 'use server'
+ return handleServerFunctions({
+ ...args,
+ config,
+ importMap,
+ })
+ }
const Layout = ({ children }: Args) => (
<RootLayout
config={config}
importMap={importMap}
+ serverFunctions={serverFunctions}
>
{children}
</RootLayout>
)
export default Layout
```
2. If you were previously posting to the `/api/form-state` endpoint, it
no longer exists. Instead, you'll need to invoke the `form-state` Server
Function, which can be done through the _new_ `getFormState` utility:
```diff
- import { getFormState } from '@payloadcms/ui'
- const { state } = await getFormState({
- apiRoute: '',
- body: {
- // ...
- },
- serverURL: ''
- })
+ const { getFormState } = useServerFunctions()
+
+ const { state } = await getFormState({
+ // ...
+ })
```
## Breaking Changes
```diff
- useFieldProps()
- useCellProps()
```
More details coming soon.
---------
Co-authored-by: Alessio Gravili <alessio@gravili.de>
Co-authored-by: Jarrod Flesch <jarrodmflesch@gmail.com>
Co-authored-by: James <james@trbl.design>
2024-11-11 13:59:05 -05:00
|
|
|
"./rsc": {
|
|
|
|
|
"import": "./dist/exports/rsc/index.js",
|
|
|
|
|
"types": "./dist/exports/rsc/index.d.ts",
|
|
|
|
|
"default": "./dist/exports/rsc/index.js"
|
|
|
|
|
},
|
2024-06-19 12:36:00 -04:00
|
|
|
"./scss/app.scss": "./dist/scss/app.scss",
|
|
|
|
|
"./styles.css": "./dist/styles.css",
|
2024-03-21 16:12:33 -04:00
|
|
|
"./assets": {
|
|
|
|
|
"import": "./dist/assets/index.js",
|
2024-06-19 12:36:00 -04:00
|
|
|
"types": "./dist/assets/index.d.ts",
|
|
|
|
|
"default": "./dist/assets/index.js"
|
feat!: prebundle payload, ui, richtext-lexical (#6579)
# Breaking Changes
### New file import locations
Exports from the `payload` package have been _significantly_ cleaned up.
Now, just about everything is able to be imported from `payload`
directly, rather than an assortment of subpath exports. This means that
things like `import { buildConfig } from 'payload/config'` are now just
imported via `import { buildConfig } from 'payload'`. The mental model
is significantly simpler for developers, but you might need to update
some of your imports.
Payload now exposes only three exports:
1. `payload` - all types and server-only Payload code
2. `payload/shared` - utilities that can be used in either the browser
or in Node environments
3. `payload/node` - heavy utilities that should only be imported in Node
scripts and never be imported into bundled code like Next.js
### UI library pre-bundling
With this release, we've dramatically sped up the compile time for
Payload by pre-bundling our entire UI package for use inside of the
Payload admin itself. There are new exports that should be used within
Payload custom components:
1. `@payloadcms/ui/client` - all client components
2. `@payloadcms/ui/server` - all server components
For all of your custom Payload admin UI components, you should be
importing from one of these two pre-compiled barrel files rather than
importing from the more deeply nested exports directly. That will keep
compile times nice and speedy, and will also make sure that the bundled
JS for your admin UI is kept small.
For example, whereas before, if you imported the Payload `Button`, you
would have imported it like this:
```ts
import { Button } from '@payloadcms/ui/elements/Button'
```
Now, you would import it like this:
```ts
import { Button } from '@payloadcms/ui/client'
```
This is a significant DX / performance optimization that we're pretty
pumped about.
However, if you are importing or re-using Payload UI components
_outside_ of the Payload admin UI, for example in your own frontend
apps, you can import from the individual component exports which will
make sure that the bundled JS is kept to a minimum in your frontend
apps. So in your own frontend, you can continue to import directly to
the components that you want to consume rather than importing from the
pre-compiled barrel files.
Individual component exports will now come with their corresponding CSS
and everything will work perfectly as-expected.
### Specific exports have changed
- `'@payloadcms/ui/templates/Default'` and
`'@payloadcms/ui/templates/Minimal`' are now exported from
`'@payloadcms/next/templates'`
- Old: `import { LogOut } from '@payloadcms/ui/icons/LogOut'` new:
`import { LogOutIcon } from '@payloadcms/ui/icons/LogOut'`
## Background info
In effort to make local dev as fast as possible, we need to import as
few files as possible so that the compiler has less to process. One way
we've achieved this in the Admin Panel was to _remove_ all .scss imports
from all components in the `@payloadcms/ui` module using a build
process. This stripped all `import './index.scss'` statements out of
each component before injecting them into `dist`. Instead, it bundles
all of the CSS into a single `main.css` file, and we import _that_ at
the root of the app.
While this concept is _still_ the right solution to the problem, this
particular approach is not viable when using these components outside
the Admin Panel, where not only does this root stylesheet not exist, but
where it would also bloat your app with unused styles. Instead, we need
to _keep_ these .scss imports in place so they are imported directly
alongside your components, as expected. Then, we need create a _new_
build step that _separately_ compiles the components _without_ their
stylesheets—this way your app can consume either as needed from the new
`client` and `server` barrel files within `@payloadcms/ui`, i.e. from
within `@payloadcms/next` and all other admin-specific packages and
plugins.
This way, all other applications will simply import using the direct
file paths, just as they did before. Except now they come with
stylesheets.
And we've gotten a pretty awesome initial compilation performance boost.
---------
Co-authored-by: James <james@trbl.design>
Co-authored-by: Alessio Gravili <alessio@gravili.de>
2024-06-17 14:25:36 -04:00
|
|
|
},
|
feat!: on demand rsc (#8364)
Currently, Payload renders all custom components on initial compile of
the admin panel. This is problematic for two key reasons:
1. Custom components do not receive contextual data, i.e. fields do not
receive their field data, edit views do not receive their document data,
etc.
2. Components are unnecessarily rendered before they are used
This was initially required to support React Server Components within
the Payload Admin Panel for two key reasons:
1. Fields can be dynamically rendered within arrays, blocks, etc.
2. Documents can be recursively rendered within a "drawer" UI, i.e.
relationship fields
3. Payload supports server/client component composition
In order to achieve this, components need to be rendered on the server
and passed as "slots" to the client. Currently, the pattern for this is
to render custom server components in the "client config". Then when a
view or field is needed to be rendered, we first check the client config
for a "pre-rendered" component, otherwise render our client-side
fallback component.
But for the reasons listed above, this pattern doesn't exactly make
custom server components very useful within the Payload Admin Panel,
which is where this PR comes in. Now, instead of pre-rendering all
components on initial compile, we're able to render custom components
_on demand_, only as they are needed.
To achieve this, we've established [this
pattern](https://github.com/payloadcms/payload/pull/8481) of React
Server Functions in the Payload Admin Panel. With Server Functions, we
can iterate the Payload Config and return JSX through React's
`text/x-component` content-type. This means we're able to pass
contextual props to custom components, such as data for fields and
views.
## Breaking Changes
1. Add the following to your root layout file, typically located at
`(app)/(payload)/layout.tsx`:
```diff
/* THIS FILE WAS GENERATED AUTOMATICALLY BY PAYLOAD. */
/* DO NOT MODIFY IT BECAUSE IT COULD BE REWRITTEN AT ANY TIME. */
+ import type { ServerFunctionClient } from 'payload'
import config from '@payload-config'
import { RootLayout } from '@payloadcms/next/layouts'
import { handleServerFunctions } from '@payloadcms/next/utilities'
import React from 'react'
import { importMap } from './admin/importMap.js'
import './custom.scss'
type Args = {
children: React.ReactNode
}
+ const serverFunctions: ServerFunctionClient = async function (args) {
+ 'use server'
+ return handleServerFunctions({
+ ...args,
+ config,
+ importMap,
+ })
+ }
const Layout = ({ children }: Args) => (
<RootLayout
config={config}
importMap={importMap}
+ serverFunctions={serverFunctions}
>
{children}
</RootLayout>
)
export default Layout
```
2. If you were previously posting to the `/api/form-state` endpoint, it
no longer exists. Instead, you'll need to invoke the `form-state` Server
Function, which can be done through the _new_ `getFormState` utility:
```diff
- import { getFormState } from '@payloadcms/ui'
- const { state } = await getFormState({
- apiRoute: '',
- body: {
- // ...
- },
- serverURL: ''
- })
+ const { getFormState } = useServerFunctions()
+
+ const { state } = await getFormState({
+ // ...
+ })
```
## Breaking Changes
```diff
- useFieldProps()
- useCellProps()
```
More details coming soon.
---------
Co-authored-by: Alessio Gravili <alessio@gravili.de>
Co-authored-by: Jarrod Flesch <jarrodmflesch@gmail.com>
Co-authored-by: James <james@trbl.design>
2024-11-11 13:59:05 -05:00
|
|
|
"./elements/RenderServerComponent": {
|
|
|
|
|
"import": "./dist/elements/RenderServerComponent/index.js",
|
|
|
|
|
"types": "./dist/elements/RenderServerComponent/index.d.ts",
|
|
|
|
|
"default": "./dist/elements/RenderServerComponent/index.js"
|
|
|
|
|
},
|
2024-03-21 16:12:33 -04:00
|
|
|
"./elements/*": {
|
|
|
|
|
"import": "./dist/elements/*/index.js",
|
2024-06-19 12:36:00 -04:00
|
|
|
"types": "./dist/elements/*/index.d.ts",
|
|
|
|
|
"default": "./dist/elements/*/index.js"
|
2024-03-21 16:12:33 -04:00
|
|
|
},
|
|
|
|
|
"./fields/*": {
|
|
|
|
|
"import": "./dist/fields/*/index.js",
|
2024-06-19 12:36:00 -04:00
|
|
|
"types": "./dist/fields/*/index.d.ts",
|
|
|
|
|
"default": "./dist/fields/*/index.js"
|
2024-03-21 16:12:33 -04:00
|
|
|
},
|
perf(richtext-lexical)!: significantly reduce lexical rerendering and amount of network requests from blocks (#9255)
The field RSC now provides an initial state for all lexical blocks. This
completely obliterates any flashes and lexical block loading states when
loading or saving a document.
Previously, when a document is loaded or saved, every lexical block was
sending a network request in order to fetch their form state. Now, this
is batched and handled in the lexical server component. All lexical
block form states are sent to the client together with the parent
lexical field, and are thus available immediately.
We also do the same with block collapsed preferences. Thus, there are no
loading states or layout shifts/flashes of blocks anymore.
Additionally, when saving a document while your cursor is inside a
lexical field, the cursor position is preserved. Previously, a document
save would kick your cursor out of the lexical field.
## Look at how nice this is:
https://github.com/user-attachments/assets/21d736d4-8f80-4df0-a782-7509edd993da
**BREAKING:**
This removes the `feature.hooks.load` and `feature.hooks.save`
interfaces from custom lexical features, as they weren't used internally
and added unnecessary, additional overhead.
If you have custom features that use those, you can migrate to using
normal payload hooks that run on the server instead of the client.
2024-11-17 01:31:55 -07:00
|
|
|
"./forms/fieldSchemasToFormState": {
|
|
|
|
|
"import": "./dist/forms/fieldSchemasToFormState/index.js",
|
|
|
|
|
"types": "./dist/forms/fieldSchemasToFormState/index.d.ts",
|
|
|
|
|
"default": "./dist/forms/fieldSchemasToFormState/index.js"
|
|
|
|
|
},
|
|
|
|
|
"./forms/renderField": {
|
|
|
|
|
"import": "./dist/forms/fieldSchemasToFormState/renderField.js",
|
|
|
|
|
"types": "./dist/forms/fieldSchemasToFormState/renderField.d.ts",
|
|
|
|
|
"default": "./dist/forms/fieldSchemasToFormState/renderField.js"
|
|
|
|
|
},
|
2024-03-21 16:12:33 -04:00
|
|
|
"./forms/*": {
|
|
|
|
|
"import": "./dist/forms/*/index.js",
|
2024-06-19 12:36:00 -04:00
|
|
|
"types": "./dist/forms/*/index.d.ts",
|
|
|
|
|
"default": "./dist/forms/*/index.js"
|
2024-03-21 16:12:33 -04:00
|
|
|
},
|
|
|
|
|
"./graphics/*": {
|
|
|
|
|
"import": "./dist/graphics/*/index.js",
|
2024-06-19 12:36:00 -04:00
|
|
|
"types": "./dist/graphics/*/index.d.ts",
|
|
|
|
|
"default": "./dist/graphics/*/index.js"
|
2024-03-21 16:12:33 -04:00
|
|
|
},
|
|
|
|
|
"./hooks/*": {
|
|
|
|
|
"import": "./dist/hooks/*.js",
|
2024-06-19 12:36:00 -04:00
|
|
|
"types": "./dist/hooks/*.d.ts",
|
|
|
|
|
"default": "./dist/hooks/*.js"
|
2024-03-21 16:12:33 -04:00
|
|
|
},
|
|
|
|
|
"./icons/*": {
|
|
|
|
|
"import": "./dist/icons/*/index.js",
|
2024-06-19 12:36:00 -04:00
|
|
|
"types": "./dist/icons/*/index.d.ts",
|
|
|
|
|
"default": "./dist/icons/*/index.js"
|
2024-03-21 16:12:33 -04:00
|
|
|
},
|
|
|
|
|
"./providers/*": {
|
|
|
|
|
"import": "./dist/providers/*/index.js",
|
2024-06-19 12:36:00 -04:00
|
|
|
"types": "./dist/providers/*/index.d.ts",
|
|
|
|
|
"default": "./dist/providers/*/index.js"
|
2024-03-21 16:12:33 -04:00
|
|
|
},
|
|
|
|
|
"./utilities/*": {
|
|
|
|
|
"import": "./dist/utilities/*.js",
|
2024-06-19 12:36:00 -04:00
|
|
|
"types": "./dist/utilities/*.d.ts",
|
|
|
|
|
"default": "./dist/utilities/*.js"
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"main": "./dist/exports/client/index.js",
|
|
|
|
|
"types": "./dist/exports/client/index.d.ts"
|
2024-04-25 22:19:37 -04:00
|
|
|
}
|
2023-11-15 16:00:45 -05:00
|
|
|
}
|