#Accessing non-prop data inside of resolveData

1 messages · Page 1 of 1 (latest)

rigid lily
#

Hi,

I was wondering if there was a creative way to pass additional data down to the resolveData function outside of props.

The use case is that I want the config created by Puck to be useable across pages rather than one-off pages aka use Puck to create a sharable template. To make this happen, the API I need to call inside of resolveData needs to be able to call different parameters depending on the page.

I could grab the the query params at my /edit path from the the URL every time resolveData is called but that's not ideal. I have tried accessing state here but that doesn't work because the function is outside of a component. This is also data that shouldn't be passed via props.

Can anyone thing of a creative way to access this kind of shared data in resolveData?

round pasture
#

Hey @rigid lily. Would love to give you some pointers but I'm not sure I totally understand what you're trying to achieve.

Are you looking to set the props based on the page, or actual Puck config?

And how is the "page" determined here? By URL? By another Puck prop?

rigid lily
#

I'm trying to use the same configuration for multiple pages using URL parameters. So if it's configuration for my product page, the API call needs to be different depending on which product ID is specified in the URL. For all my different components, I could grab the URL params from the window object on each resolveProps call, but I was seeing if there's a better way to do that.

#

url looks something like templateId=product&entityId=air-force-1

round pasture
#

right, so you have a single Config, and want to change the default based on the query params.

#

Does the user need to be able to edit these props?

rigid lily
#

So for the prototype I'm trying to put together, no, but it could be cool if the user could see the prop values on the right side in the locked/read-only view. For example, the developer would author a Hero component and map the title prop to the the name field on the product entity that is fetched from the CMS. The user who is dragging the Hero component on the page WOULD NOT be the one making this mapping. It seems like resolveData should play a role here to get the correct data when the product changes.

In the future, it would be cool if the user could actually write back to the CMS. For example, change the title prop and behind the scenes that's changing the name field for the product in the CMS, but I'm not really worried about this for right now.

round pasture
#

Are the templates opinionated, too?

Have you considered generating the data payload before passing it to Puck, rather than dynamically populating the fields in resolveData? And then using resolveData to set the fields as readOnly within the components?

Having said that, I don't hate the idea of using resolveData for each of these components, because each component will require different logic. If you want to avoid repeating API calls, you could store the data in a global variable, outside of the React scope.

Perhaps it might be interesting to add extra data arg to the resolveData function in future, but I'm not convinced of that yet.

rigid lily
#

Are the templates opinionated, too?
Lmk if this answers your question: At some point, it would be great to limit components to certain templates. For example, I would want the ProductHero to only be useable on the Product template and not the location template.

Have you considered generating the data payload before passing it to Puck, rather than dynamically populating the fields in resolveData?
I'm not sure how this would work. I guess I could just not have the external data be props at all. For example, the data is fetched and added to context that the component accesses and uses. I just thought it could be cool to show the values as read only props with the long-term goal as having those fields actually write back to the CMS on save