13 Commits

Author	SHA1	Message	Date
T. R. Bernstein	4a5f01a78f	chore: Update code to new repo	2025-10-08 23:27:45 +02:00
Germán Jabloñski	97e2e77ff4	chore: run dev:generate-types (#11994)	2025-04-08 17:25:29 -03:00
Sasha	117949b8d9	test: regenerate payload-types.ts for all test suites (#11238) ... Regenerates `payload-types.ts` for all test suites.	2025-02-18 00:45:59 +02:00
Alessio Gravili	c7138b9aab	chore: update generated types for all test suites (#9577)	2024-11-27 20:36:37 +00: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	dc12047723	feat: reduce package size and amount of dependencies by upgrading json-schema-to-typescript (#7938) ... Closes https://github.com/payloadcms/payload/issues/7934	2024-08-28 21:59:32 +00:00
Alessio Gravili	e5d5126d14	chore: regenerate all types in test dir, and add to eslint & prettier ignores	2024-07-11 15:59:38 -04: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
Elliot DeNolf	354ad7092c	chore: type gen formatting (#6309)	2024-05-09 23:55:55 -04:00
Alessio Gravili	f7a2cf96b9	chore: properly working generated types within tests (#6288)	2024-05-09 17:12:51 -04:00
James	0f3b364e46	chore: hoists tests out of payload package	2023-09-01 14:45:41 -04:00
Alessio Gravili	a67278b29f	chore: move to monorepo structure	2023-08-23 12:20:30 +02:00
Elliot DeNolf	2198445df9	Feat/migrations cli (#2940) ... * feat: migrate cli call db adapter * feat: mongoose adapter migrate:create * feat: implement migrate command * feat: use mongooseAdapter in test config * feat: use filename as migration name * feat: intelligently execute migrations, status table * feat: implement migrate:down * feat: implement migrate:reset * feat: implement migrate:refresh * feat: move common adapter operations to database/migrations dir * feat: delete migrations instead of storing ran property * feat: createMigration cleanup * feat: clean up logging and add duration to output * chore: export type, handle graphQL false * chore: simplify getting latest batch number * chore: remove existing migration logging noise * feat: remove adapter export from top level * chore: fix some db types	2023-07-07 11:02:56 -04:00