21 Commits

Author	SHA1	Message	Date
T. R. Bernstein	4a5f01a78f	chore: Update code to new repo	2025-10-08 23:27:45 +02:00
Jacob Fletcher	c96fa613bc	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
Alessio Gravili	86fdad0bb8	chore: significantly improve eslint performance, lint and prettier everything	2024-08-29 21:25:50 -04:00
Alessio Gravili	90b7b20699	feat!: beta-next (#7620) ... This PR makes three major changes to the codebase: 1. [Component Paths](#component-paths) Instead of importing custom components into your config directly, they are now defined as file paths and rendered only when needed. That way the Payload config will be significantly more lightweight, and ensures that the Payload config is 100% server-only and Node-safe. Related discussion: https://github.com/payloadcms/payload/discussions/6938 2. [Client Config](#client-config) Deprecates the component map by merging its logic into the client config. The main goal of this change is for performance and simplification. There was no need to deeply iterate over the Payload config twice, once for the component map, and another for the client config. Instead, we can do everything in the client config one time. This has also dramatically simplified the client side prop drilling through the UI library. Now, all components can share the same client config which matches the exact shape of their Payload config (with the exception of non-serializable props and mapped custom components). 3. [Custom client component are no longer server-rendered](#custom-client-components-are-no-longer-server-rendered) Previously, custom components would be server-rendered, no matter if they are server or client components. Now, only server components are rendered on the server. Client components are automatically detected, and simply get passed through as `MappedComponent` to be rendered fully client-side. ## Component Paths Instead of importing custom components into your config directly, they are now defined as file paths and rendered only when needed. That way the Payload config will be significantly more lightweight, and ensures that the Payload config is 100% server-only and Node-safe. Related discussion: https://github.com/payloadcms/payload/discussions/6938 In order to reference any custom components in the Payload config, you now have to specify a string path to the component instead of importing it. Old: ```ts import { MyComponent2} from './MyComponent2.js' admin: { components: { Label: MyComponent2 }, }, ``` New: ```ts admin: { components: { Label: '/collections/Posts/MyComponent2.js#MyComponent2', // <= has to be a relative path based on a baseDir configured in the Payload config - NOT relative based on the importing file }, }, ``` ### Local API within Next.js routes Previously, if you used the Payload Local API within Next.js pages, all the client-side modules are being added to the bundle for that specific page, even if you only need server-side functionality. This `/test` route, which uses the Payload local API, was previously 460 kb. It is now down to 91 kb and does not bundle the Payload client-side admin panel anymore. All tests done [here](https://github.com/payloadcms/payload-3.0-demo/tree/feat/path-test) with beta.67/PR, db-mongodb and default richtext-lexical: **dev /admin before:**  **dev /admin after:**  --- **dev /test before:**  **dev /test after:**  --- **build before:**  **build after::**  ### Usage of the Payload Local API / config outside of Next.js This will make it a lot easier to use the Payload config / local API in other, server-side contexts. Previously, you might encounter errors due to client files (like .scss files) not being allowed to be imported. ## Client Config Deprecates the component map by merging its logic into the client config. The main goal of this change is for performance and simplification. There was no need to deeply iterate over the Payload config twice, once for the component map, and another for the client config. Instead, we can do everything in the client config one time. This has also dramatically simplified the client side prop drilling through the UI library. Now, all components can share the same client config which matches the exact shape of their Payload config (with the exception of non-serializable props and mapped custom components). This is breaking change. The `useComponentMap` hook no longer exists, and most component props have changed (for the better): ```ts const { componentMap } = useComponentMap() // old const { config } = useConfig() // new ``` The `useConfig` hook has also changed in shape, `config` is now a property _within_ the context obj: ```ts const config = useConfig() // old const { config } = useConfig() // new ``` ## Custom Client Components are no longer server rendered Previously, custom components would be server-rendered, no matter if they are server or client components. Now, only server components are rendered on the server. Client components are automatically detected, and simply get passed through as `MappedComponent` to be rendered fully client-side. The benefit of this change: Custom client components can now receive props. Previously, the only way for them to receive dynamic props from a parent client component was to use hooks, e.g. `useFieldProps()`. Now, we do have the option of passing in props to the custom components directly, if they are client components. This will be simpler than having to look for the correct hook. This makes rendering them on the client a little bit more complex, as you now have to check if that component is a server component (=> already has been rendered) or a client component (=> not rendered yet, has to be rendered here). However, this added complexity has been alleviated through the easy-to-use `<RenderMappedComponent />` helper. This helper now also handles rendering arrays of custom components (e.g. beforeList, beforeLogin ...), which actually makes rendering custom components easier in some cases. ## Misc improvements This PR includes misc, breaking changes. For example, we previously allowed unions between components and config object for the same property. E.g. for the custom view property, you were allowed to pass in a custom component or an object with other properties, alongside a custom component. Those union types are now gone. You can now either pass an object, or a component. The previous `{ View: MyViewComponent}` is now `{ View: { Component: MyViewComponent} }` or `{ View: { Default: { Component: MyViewComponent} } }`. This dramatically simplifies the way we read & process those properties, especially in buildComponentMap. We can now simply check for the existence of one specific property, which always has to be a component, instead of running cursed runtime checks on a shared union property which could contain a component, but could also contain functions or objects.   - [x] I have read and understand the [CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md) document in this repository. --------- Co-authored-by: PatrikKozak <patrik@payloadcms.com> Co-authored-by: Paul <paul@payloadcms.com> Co-authored-by: Paul Popus <paul@nouance.io> Co-authored-by: Jacob Fletcher <jacobsfletch@gmail.com> Co-authored-by: James <james@trbl.design>	2024-08-13 12:54:33 -04:00
Jacob Fletcher	97837f0708	feat(ui)!: passes field props to custom components (#7360) ... ## Description Currently, there is no way to read field props from within a custom field component, i.e. `admin.components.Description`. For example, if you set `maxLength: 100` on your field, your custom description component cannot read it from `props.maxLength` or any other methods. Because these components are rendered on the server, there is also no way of using `admin.component.Field` to inject custom props yourself, either. To support this, we can simply pass the base component props into these components on the server, as expected. This has also led to custom field component props becoming more strictly typed within the config. This change is considered breaking only because the types have changed. This only affects you if you were previously importing the following types into your own custom components. To migrate, simply change the import paths for that type. Old: ```ts import type { ArrayFieldProps, ReducedBlock, BlocksFieldProps, CheckboxFieldProps, CodeFieldProps, CollapsibleFieldProps, DateFieldProps, EmailFieldProps, GroupFieldProps, HiddenFieldProps, JSONFieldProps, NumberFieldProps, PointFieldProps, RadioFieldProps, RelationshipFieldProps, RichTextComponentProps, RowFieldProps, SelectFieldProps, TabsFieldProps, TextFieldProps, TextareaFieldProps, UploadFieldProps, ErrorProps, FormFieldBase, FieldComponentProps, FieldMap, MappedField, MappedTab, ReducedBlock, } from '@payloadcms/ui' ``` New: ```ts import type { FormFieldBase, // etc. } from 'payload' ``` Custom field components are now much more strongly typed. To make this happen, an explicit type for every custom component has been generated for every field type. The convention is to append `DescriptionComponent`, `LabelComponent`, and `ErrorComponent` onto the end of the field name, i.e. `TextFieldDescriptionComponent`. Here's an example: ```ts import type { TextFieldDescriptionComponent } from 'payload' import React from 'react' export const CustomDescription: TextFieldDescriptionComponent = (props) => { return ( <div id="custom-field-description">{`The max length of this field is: ${props?.maxLength}`}</div> ) } ``` Here's the full list of all new types: Label Components: ```ts import type { ArrayFieldLabelComponent, BlocksFieldLabelComponent, CheckboxFieldLabelComponent, CodeFieldLabelComponent, CollapsibleFieldLabelComponent, DateFieldLabelComponent, EmailFieldLabelComponent, GroupFieldLabelComponent, HiddenFieldLabelComponent, JSONFieldLabelComponent, NumberFieldLabelComponent, PointFieldLabelComponent, RadioFieldLabelComponent, RelationshipFieldLabelComponent, RichTextFieldLabelComponent, RowFieldLabelComponent, SelectFieldLabelComponent, TabsFieldLabelComponent, TextFieldLabelComponent, TextareaFieldLabelComponent, UploadFieldLabelComponent } from 'payload' ``` Error Components: ```tsx import type { ArrayFieldErrorComponent, BlocksFieldErrorComponent, CheckboxFieldErrorComponent, CodeFieldErrorComponent, CollapsibleFieldErrorComponent, DateFieldErrorComponent, EmailFieldErrorComponent, GroupFieldErrorComponent, HiddenFieldErrorComponent, JSONFieldErrorComponent, NumberFieldErrorComponent, PointFieldErrorComponent, RadioFieldErrorComponent, RelationshipFieldErrorComponent, RichTextFieldErrorComponent, RowFieldErrorComponent, SelectFieldErrorComponent, TabsFieldErrorComponent, TextFieldErrorComponent, TextareaFieldErrorComponent, UploadFieldErrorComponent } from 'payload' ``` Description Components: ```tsx import type { ArrayFieldDescriptionComponent, BlocksFieldDescriptionComponent, CheckboxFieldDescriptionComponent, CodeFieldDescriptionComponent, CollapsibleFieldDescriptionComponent, DateFieldDescriptionComponent, EmailFieldDescriptionComponent, GroupFieldDescriptionComponent, HiddenFieldDescriptionComponent, JSONFieldDescriptionComponent, NumberFieldDescriptionComponent, PointFieldDescriptionComponent, RadioFieldDescriptionComponent, RelationshipFieldDescriptionComponent, RichTextFieldDescriptionComponent, RowFieldDescriptionComponent, SelectFieldDescriptionComponent, TabsFieldDescriptionComponent, TextFieldDescriptionComponent, TextareaFieldDescriptionComponent, UploadFieldDescriptionComponent } from 'payload' ``` This PR also: - Standardizes the `FieldBase['label']` type with a new `LabelStatic` type. This makes type usage much more consistent across components. - Simplifies some of the typings in the field component map, removes unneeded `<Omit>`, etc. - Fixes misc. linting issues around voiding promises - [x] I have read and understand the [CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md) document in this repository. ## Type of change - [x] New feature (non-breaking change which adds functionality) ## Checklist: - [x] I have added tests that prove my fix is effective or that my feature works - [x] Existing test suite passes locally with my changes - [x] I have made corresponding changes to the documentation	2024-07-26 14:03:25 -04:00
Alessio Gravili	83fd4c6622	chore: run lint and prettier on entire codebase	2024-07-11 15:27:01 -04:00
Alessio Gravili	aef2a52cea	fix: fix all ui imports in our plugins, and get rid of ui subpath exports within monorepo (#6854)	2024-06-19 14:16:31 -04:00
Alessio Gravili	bc98567f41	feat!: rename @payloadcms/ui/client to @payloadcms/ui, and other auto-suggestion & exports improvements (#6848) ... **BREAKING:** All `@payloadcms/ui/client` exports have been renamed to `@payloadcms/ui`. A simple find & replace across your entire project will be enough to migrate. This change greatly improves import auto-completions in IDEs which lack proper support for package.json exports, like Webstorm.	2024-06-19 16:36:00 +00:00
Jacob Fletcher	9e76c8f4e3	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
Alessio Gravili	7ec37e058e	chore: adjust imports for richtext-slate	2024-03-20 10:07:30 -04:00
Alessio Gravili	50c7269315	chore: replace .d.ts type imports with .js imports, as .d.ts imports break usage checks in the IDE	2024-03-07 16:08:49 -05:00
James	a2aa527f50	chore: removes default exports from slate	2024-03-06 19:29:04 -05:00
Alessio Gravili	11498dcc7f	chore(richtext-slate): use normal exports for field and cell components	2024-03-06 18:54:36 -05:00
PatrikKozak	c52736372a	chore: updates richtext-slate imports to ESM	2024-03-06 15:05:04 -05:00
James	7815d5ac5d	chore: successful build	2024-03-06 11:57:24 -05:00
James	795fdd477c	chore: buildable slate	2024-02-29 14:30:47 -05:00
James	ca7b8e589e	chore: relationship slate ssr	2024-02-22 14:37:59 -05:00
James	4003a8023c	chore: defines ClientFunction pattern	2024-02-22 10:55:51 -05:00
Jarrod Flesch	717a6b6d07	feat: initial test suite framework (#4929)	2024-02-14 09:46:11 -05:00
James	6bc282444e	chore: slate compatibility with next-payload	2023-10-14 11:49:38 -04:00
Alessio Gravili	a81401cf77	feat: breaking: richtext adapter (#3311) ... BREAKING: requires user to install @payloacms-richtext-slate and specify a `config.editor` property * chore: move slate stuff into packages/richtext-slate * chore: fieldTypes stuff * chore: fix richtext-slate tsconfig * chore: add clean:unix command * chore: fix up things * chore: undo subpath imports being hoisted up * chore: fix incorrect imports * chore: improve AdapterArguments type * chore: remove unused richTextToHTML and stringifyRichText files * fix: core-dev scss imports * chore: fix publishConfig exports for richtext-slate * chore: adjust joi schema for richtext field * chore: various fixes * chore: handle afterRead population in richText adapter * chore: handle more after-read promise stuff * chore: fix joi validation * chore: add richtext adapter to tests * chore: merge adapter props with field props * chore: index.tsx => index.ts * chore: rename `adapter` to `editor` * chore: fix e2e tests not running due to importing a constant from a file (`Tabs`) which imports createSlate. This fails because createSlate imports React components. * chore: remove unnecessary import * chore: improve various typings * chore: improve typings for List view Cell components * feat: richText adapter cell component * chore: add missing types packages for packages/richtext-slate * chore: add new adapter interface properties to joi schema * chore: withMergedProps utility which replaces getSlateCellComponent and getSlateFieldComponent * feat: added config.defaultEditor property which is now required. field.editor is no longer required and overrides config.defaultEditor * docs: mention editor and defaultEditor property in the docs * chore: fix incorrectly formatted JSX in docs files breaking mdx parser * chore: fix various errors * chore: auto-generated pointer files	2023-09-19 11:03:31 +02:00