10 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	00a673e491	feat(next): regenerate live preview url on save (#13631) ... Closes #12785. Although your live preview URL can be dynamic based on document data, it is never recalculated after initial mount. This means if your URL is dependent of document data that was just changed, such as a "slug" field, the URL of the iframe does not reflect that change as expected until the window is refreshed or you navigate back. This also means that server-side live preview will crash when your front-end attempts to query using a slug that no longer exists. Here's the general flow: slug changes, autosave runs, iframe refreshes (url has old slug), 404. Now, we execute your live preview function on submit within form state, and the window responds to the new URL as expected, refreshing itself without losing its connection. Here's the result: https://github.com/user-attachments/assets/7dd3b147-ab6c-4103-8b2f-14d6bc889625 --- - To see the specific tasks where the Asana app for GitHub is being used, see below: - https://app.asana.com/0/0/1211094211063140	2025-09-23 09:37:15 -04:00
Jarrod Flesch	e5755110a9	fix(plugin-multi-tenant): selector could become hidden (#13134) ... The selector could become hidden by: - logging in with a user that only has 1 tenant - logging out - logging in with a user that has more than 1 tenant Simplifies useEffect usage. Adds e2e test for this case.	2025-07-11 16:34:55 -04:00
Alessio Gravili	c7bb694249	perf: 50% faster compilation speed by skipping bundling of server-only packages during dev (#11594) ... This PR skips bundling server-only payload packages during development, which results in 50% faster compilation speeds using turbo. Test results using our blank template (both /api and /admin): Webpack before: 11.5 Webpack now: 7.1s => 38% faster compilation speed Turbopack before: 4.1s Turbopack after: 2.1s => 50% faster compilation speed	2025-03-11 09:45:13 -06:00
Alessio Gravili	cc05937633	fix(next): admin panel fails compiling when fullySpecified is set in next config (#11531) ... If `experimental.fullySpecified` is set to `true` in the next config, the Payload admin panel fails to compile, throwing the following error: ```ts Failed to compile. ../../node_modules/.pnpm/@payloadcms+next@3.25.0-canary.46647b4_@types+react@18.3.1_graphql@16.10.0_monaco-editor@0.40_w3ro7ziou6gzev7zbe3qqrwaqe/node_modules/@payloadcms/next/dist/views/Version/RenderFieldsToDiff/fields/Select/DiffViewer/index.js Attempted import error: 'DiffMethod' is not exported from 'react-diff-viewer-continued' (imported as 'DiffMethod'). ``` The issue stems from incorrect import statements in `react-diff-viewer-continued` 4.0.4. This was fixed in `react-diff-viewer-continued` 4.0.5. This PR also enables `fullySpecified` in our test suites, to catch these issues going forward.	2025-03-05 00:04:03 +00:00
Alessio Gravili	e6fea1d132	fix: localized fields within block references were not handled properly if any parent is localized (#11207) ... The `localized` properly was not stripped out of referenced block fields, if any parent was localized. For normal fields, this is done in sanitizeConfig. As the same referenced block config can be used in both a localized and non-localized config, we are not able to strip it out inside sanitizeConfig by modifying the block config. Instead, this PR had to bring back tedious logic to handle it everywhere the `field.localized` property is accessed. For backwards-compatibility, we need to keep the existing sanitizeConfig logic. In 4.0, we should remove it to benefit from better test coverage of runtime field.localized handling - for now, this is done for our test suite using the `PAYLOAD_DO_NOT_SANITIZE_LOCALIZED_PROPERTY` flag.	2025-02-17 19:50:32 +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	ebd43c7763	feat: pre-compile ui and richtext-lexical with react compiler (#7688) ... This noticeably improves performance in the admin panel, for example when there are multiple richtext editors on one page (& likely performance in other areas too, though I mainly tested rich text). The babel plugin currently only optimizes files with a 'use client' directive at the top - thus we have to make sure to add use client wherever possible, even if it's imported by a parent client component. There's one single component that broke when it was compiled using the React compiler (it stopped being reactive and failed one of our admin e2e tests): 150808f608 opting out of it completely fixed that issue Fixes https://github.com/payloadcms/payload/issues/7366	2024-08-19 17:31:36 -04:00
Alessio Gravili	35f961fecb	feat!: next.js 15, react 19, react compiler support (#6429) ... **BREAKING:** - bumps minimum required next.js version from `14.3.0-canary.68` to `15.0.0-rc.0` - bumps minimum required react and react-dom versions to `19.0.0 `(`19.0.0-rc-f994737d14-20240522` should be used) - `@types/react` and `@types/react-dom` have to be bumped to `npm:types-react@19.0.0-beta.2` using overrides and pnpm overrides, if you want correct types. You can find an example of this here: https://github.com/payloadcms/payload/pull/6429/files#diff-10cb9e57a77733f174ee2888587281e94c31f79e434aa3f932a8ec72fa7a5121L32 ## Issues - Bunch of todos for our react-select package which is having type issues. Works fine, just type issues. Their type defs are importing JSX in a weird way, we likely just have to wait until they fix them in a future update.	2024-05-23 13:30:12 -04:00
Alessio Gravili	72c6200f17	get e2e and dev to work with test as new root directory	2024-03-19 11:31:50 -04:00