Problem/Motivation
The "resolveUrl" property in the Partytown settings doesn't work when set by this module. The Partytown API expects a JavaScript function signature, but we're only able to provide a string. The user is free to write their own hook and manually insert it into the page, but that sort of takes away from the point of this module.
See this documentation from qwik to get a sense of what the partytown settings are expecting to see.
Proposed resolution
It would be nice to just have a user provide the name of a function to call that they can define somewhere else, but in my testing I've not been able to get this to work. Perhaps because Partytown needs that function to be defined in the SW thread?
This makes it look like the hook needs to be defined directly in the partytown settings object.
Alternatively, we could just turn the resolve url field into a text area, attach ace editor to it, and then treat that field like a code editor. The script could then get mounted or written into the page somewhere, sort of like how the Asset Injector project does it.
Comments
Comment #2
abenbowComment #3
rattusrattus commentedThought you might be interested in my learnings\development implementing proxies for PartyTown on client project to get around CORS issues..
I've been using API Proxy along with the following resolveUrl PartyTown config:
While API Proxy is a great module, I actually think that it's a bit overkill for just getting around CORS and if we included a proxy endpoint in the PartyTown module then we could accept the bases, as above, on the config form and inject them into the config via drupalSettings.
Comment #4
abenbowThis is interesting! I didn't know this project existed, but I wish I had earlier. I've built proxies like this before, and it seemed like there should have been a pre-baked solution somewhere.
It looks like this is good for sites that can tolerate the extra API request on top of the existing page request, but I start to worry about sites with a lot of traffic (or a lot of tags that need to be proxied) and this API solution becoming a performance bottleneck. Do you have some notion of how this performs under load?
I do agree with you about it being a little overkill. It sort of feels like a network layer problem that the application layer is stepping in to solve. Ideally, your webserver could do this for you without Drupal getting involved. Of course, sometimes you just need a quick fix and Drupal is literally right there.
It could be a decent solution for folks who need something to launch PT fast.
Comment #6
abenbow