You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are currently moving from V2 to V3 and are having to deal with a little wart we had in place as a patch on the previous version of payload. This wart is a patch we created to add a simple row filtering feature on payload's ArrayField form.
We would like some assistance on the best way to proceed; either in helping migrating our patch or proposing a better solution.
Context (to help understand our use-case)
What we have in place is a collection with an array field that contains a list of points. These points contain a location (lon/lat) and an optional name. Conceptually they can either be checkpoints (points that have a location AND a name) or waypoints (points that only have a location -- they are used to link checkpoints together).
We show and allow the user to interact with this list in two ways:
A UI field which shows all of these points and allow users to modify their positions on a map. Each waypoint/checkpoint is movable as a google map marker, and we make use of the PayloadAPI to make all the necessary calls to update the collection. Until here, all good! Everything seems to be working fine in V3 😃 so far (see attached photo -- the left)
The "default" payload ArrayField form in a sidebar, where the users can see the list of checkpoints* & modify their name. (see attached photo -- the right sidebar)
Point #2 is the one we had created a patch for. In the sidebar we only want to show checkpoints (points with a name). So in V2 we went ahead to patch the ArrayField implementation (see attached), essentially adding an additional admin.rowFilter field:
Problem
In our move to V3 migrating this patch is proving difficult.
The first roadblock was the bundling of @payloadcms/ui, which makes it impractical to create patches (probably for the better -- as patches are an ugly solution anyway).
The second roadblock is the move to NextJS, where we realize the current ArrayField approach is not so simple to patch as in V2. Because of server vs client components, we cannot simply filter in the client component because it requires a function to filter with which cannot be passed to the client. So filtering would need to happen in a previous server component, and thus a small ugly patch is no longer adapted as the complexity of the components is more than changing 4-5 lines.
A final hurdle comes with the export values of @payloadcms/ui. It seems that importing some values doesn't always work as expected. As a small example, using the following as an array field Field gives strange errors of undefined Contexts. This issue makes it complicated to reuse payload UI components in some cases we've tried.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello!
We are currently moving from V2 to V3 and are having to deal with a little wart we had in place as a patch on the previous version of payload. This wart is a patch we created to add a simple row filtering feature on payload's ArrayField form.
We would like some assistance on the best way to proceed; either in helping migrating our patch or proposing a better solution.
Context (to help understand our use-case)
What we have in place is a collection with an array field that contains a list of points. These points contain a location (lon/lat) and an optional name. Conceptually they can either be checkpoints (points that have a location AND a name) or waypoints (points that only have a location -- they are used to link checkpoints together).
We show and allow the user to interact with this list in two ways:
Point #2 is the one we had created a patch for. In the sidebar we only want to show checkpoints (points with a name). So in V2 we went ahead to patch the ArrayField implementation (see attached), essentially adding an additional
admin.rowFilter
field:which we use like so:
Problem
In our move to V3 migrating this patch is proving difficult.
The first roadblock was the bundling of
@payloadcms/ui
, which makes it impractical to create patches (probably for the better -- as patches are an ugly solution anyway).The second roadblock is the move to NextJS, where we realize the current
ArrayField
approach is not so simple to patch as in V2. Because of server vs client components, we cannot simply filter in the client component because it requires a function to filter with which cannot be passed to the client. So filtering would need to happen in a previous server component, and thus a small ugly patch is no longer adapted as the complexity of the components is more than changing 4-5 lines.A final hurdle comes with the export values of
@payloadcms/ui
. It seems that importing some values doesn't always work as expected. As a small example, using the following as an array fieldField
gives strange errors of undefined Contexts. This issue makes it complicated to reuse payload UI components in some cases we've tried.used as
Surely this is a mistake from our side, but it is quite unclear to us.
Our Questions
TLDR; We need a way to configure filtering of
ArrayRow
s, based on the data of those rows.ArrayField
component?rowFilter
be a feature the payload team would consider adding to payload?Beta Was this translation helpful? Give feedback.
All reactions