-
Notifications
You must be signed in to change notification settings - Fork 3.2k
feat!: on demand rsc #8364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
feat!: on demand rsc #8364
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Sep 27, 2024
…ey are leaf fields
… into feat/on-demand-rsc
… fields with subfields
… into feat/on-demand-rsc
…Submit form hooks, leading to server action errors as client components were passed to the server action
…ildren are correct
… into feat/on-demand-rsc
|
No dependency changes detected. Learn more about Socket for GitHub ↗︎ 👍 No dependency changes detected in pull request |
…hat is caused by server actions being aborted
…to feat/on-demand-rsc
Contributor
|
🚀 This is included in version v3.0.0-beta.128 |
|
the multitenant sample is now broken, it would be cool if this could be fixed |
jacobsfletch
added a commit
that referenced
this pull request
Nov 26, 2024
When using the `admin.hidden: true` property on a collection, it rightfully removes all navigation and routing for that particular collection. However, this also affects the expected behavior of hidden entities when they are rendered within a drawer, such as the document drawer or list drawer. For example, when creating a new _admin.hidden_ document through the relationship or join field, the drawer should still render the view, despite the underlying route for that view being disabled. This change was a result of the introduction of on-demand server components in #8364, where we now make a server roundtrip to render the view in its entirety, which include the logic that redirects these hidden entities. Now, we pass a new `overrideEntityVisibility` argument through the server function that, when true, skips this step. This way documents can continue to respect `admin.hidden` while also having the ability to override on a case-by-case basis throughout the UI.
kendelljoseph
pushed a commit
that referenced
this pull request
Feb 21, 2025
When using the `admin.hidden: true` property on a collection, it rightfully removes all navigation and routing for that particular collection. However, this also affects the expected behavior of hidden entities when they are rendered within a drawer, such as the document drawer or list drawer. For example, when creating a new _admin.hidden_ document through the relationship or join field, the drawer should still render the view, despite the underlying route for that view being disabled. This change was a result of the introduction of on-demand server components in #8364, where we now make a server roundtrip to render the view in its entirety, which include the logic that redirects these hidden entities. Now, we pass a new `overrideEntityVisibility` argument through the server function that, when true, skips this step. This way documents can continue to respect `admin.hidden` while also having the ability to override on a case-by-case basis throughout the UI.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, Payload renders all custom components on initial compile of the admin panel. This is problematic for two key reasons:
This was initially required to support React Server Components within the Payload Admin Panel for a few reasons:
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 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-componentcontent-type. This means we're able to pass contextual props to custom components, such as data for fields and views.Breaking Changes
Add the following to your root layout file, typically located at
(app)/(payload)/layout.tsx:If you were previously posting to the
/api/form-stateendpoint, it no longer exists. Instead, you'll need to invoke theform-stateServer Function, which can be done through the newgetFormStateutility:Multiple layer of React Context were removed in favor of direct props. As a result, the following React hooks were removed:
If you were previously using any of these hooks, for example to access field
pathorcellData, you can now access that directly from thepropsobject.The
fieldprop also no longer contains a_schemaPathproperty. Instead, this is now also accessed directly through props: