Skip to content
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

Unnecessary JS during dynamic import #6598

Closed
MarcinRapacz opened this issue Jun 2, 2024 · 4 comments
Closed

Unnecessary JS during dynamic import #6598

MarcinRapacz opened this issue Jun 2, 2024 · 4 comments
Labels

Comments

@MarcinRapacz
Copy link

Link to reproduction

No response

Payload Version

3.0.0-beta.36

Node Version

20.10

Next.js Version

15.0.0-rc.0

Describe the Bug

When using dynamically imported components in the demo, the amount of JS downloaded when entering the page increases from ~400 kB to 670 kB.

Code changes: MarcinRapacz/payload-demo-3.0.0-beta.36@979b74c

It looks like an additional chunk is being downloaded, which seems to be JS from Payload.

Demo:
image

After:
image

Reproduction Steps

  1. Compare the production version of the demo with the production version with the changes.
  2. Run pnpm build
  3. Run pnpm start

Adapters and Plugins

No response

@MarcinRapacz MarcinRapacz added status: needs-triage Possible bug which hasn't been reproduced yet v3 labels Jun 2, 2024
@MarcinRapacz
Copy link
Author

Here's another example, but instead of using dynamic imports, I use 'use client' in one of the components.
MarcinRapacz/payload-demo-3.0.0-beta.36@06c47ed

@jmikrut
Copy link
Member

jmikrut commented Jun 10, 2024

Hey @MarcinRapacz — this is being tracked here:

vercel/next.js#65415

Hopefully we will have a fix for this one way or another shortly. Keep an eye out on that PR!

@jmikrut jmikrut closed this as completed Jun 10, 2024
@github-actions github-actions bot removed the status: needs-triage Possible bug which hasn't been reproduced yet label Jun 10, 2024
jacobsfletch pushed a commit that referenced this issue Aug 5, 2024
This PR ensures that the payload config is 100% server-only. 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 3.0 release does not rely on
vercel/next.js#65415 which will likely will not
get merged. Now, the Payload config will be significantly more
lightweight.

Related discussion:
#6938

## The issue

This PR fixes a few issues:

#4085
#6598
#6441
#7261 #7339

### 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:**
![CleanShot 2024-07-29 at 22 49
12@2x](https://github.com/user-attachments/assets/4428e766-b368-4bcf-8c18-d0187ab64f3e)

**dev /admin after:**
![CleanShot 2024-07-29 at 22 50
49@2x](https://github.com/user-attachments/assets/f494c848-7247-4b02-a650-a3fab4000de6)

---

**dev /test before:**
![CleanShot 2024-07-29 at 22 56
18@2x](https://github.com/user-attachments/assets/1a7e9500-b859-4761-bf63-abbcdac6f8d6)

**dev /test after:**
![CleanShot 2024-07-29 at 22 47
45@2x](https://github.com/user-attachments/assets/f89aa76d-f2d5-4572-9753-2267f034a45a)

---

**build before:**
![CleanShot 2024-07-29 at 22 57
14@2x](https://github.com/user-attachments/assets/5f8f7281-2a4a-40a5-a788-c30ddcdd51b5)

**build after::**
![CleanShot 2024-07-29 at 22 56
39@2x](https://github.com/user-attachments/assets/ea8772fd-512f-4db0-9a81-4b014715a1b7)

### 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.

### Custom Client Components are not server-rendered anymore

Previously, custom components would be server-rendered in
`buildComponentMap`, no matter if they are server or client components.
Now, only server components are rendered in `buildComponentMap`. Client
components simply get passed through, using `MappedComponent` as a
container. It is then the client's responsibility to render those.

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.

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,

### 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.

![CleanShot 2024-07-29 at 23 07
07@2x](https://github.com/user-attachments/assets/1e75aa4c-7a4c-419f-9070-216bb7b9a5e5)

![CleanShot 2024-07-29 at 23 09
40@2x](https://github.com/user-attachments/assets/b4c96450-6b7e-496c-a4f7-59126bfd0991)


## Custom Components

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.

E.g.

```ts
import { MyComponent2} from './MyComponent2.js'

admin: {
  components: {
    Label: MyComponent2
  },
},
```

Now becomes:

```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
  },
},
```

## Concepts: MappedComponent and PayloadComponent

Instead of `React.FC` / `React.ComponentType`, props within the payload
config that accept components now accept `PayloadComponent`. These are
basically the paths to the component. They can be a string, or an object
containing other properties like serverProps and clientProps - giving
you full control over the props this component will eventually receive.

`MappedComponent` is the result of buildComponentMap processing all
those `PayloadComponent`s. It contains the server-rendered component, or
unrendered/rendered client component. Any `MappedComponent` can be
rendered on both either the client and the server using the
`RenderMappedComponent` helper component.

## Try it out
This can be tested out here:
https://github.com/payloadcms/payload-3.0-demo/tree/feat/path-test

## Todo
- Migrate all payload plugins to new import pattern & get it to build
- Migrate test suites to new import pattern
- Clean-up, simplify component handling within core, add JSDocs
- Add Docs
- Collect all breaking changes

---------

Co-authored-by: PatrikKozak <[email protected]>
Co-authored-by: Paul <[email protected]>
Co-authored-by: Paul Popus <[email protected]>
@AlessioGr AlessioGr mentioned this issue Aug 13, 2024
1 task
@AlessioGr
Copy link
Member

This has been fixed by #7620

Copy link

github-actions bot commented Sep 6, 2024

This issue has been automatically locked.
Please open a new issue if this issue persists with any additional detail.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants