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
I am in a tight spot where I have to do a very strange setup in the browser. I have to embed segment within an iframe so as to ensure its globals are not messed with. There are multiple other third parties messing with globals, e.g. polyfills, hooked fetch function, incorrectly hooked functions, etc. In particular there is one strange third party hook that assumes that when the global identifier fetch exists that Request and friends also exist, which is not always the case in old browsers.
Embedding in an iframe is not ideal. I have 30kb of polyfill code in the top frame, and now I have to duplicate this polyfill code into the iframe. In particular, I have to do things like polyfill Promise.prototype.finally, which Segment uses but is not well supported in older browsers (e.g. Safari 10). I noticed that Segment is building with ts loader in one of examples, and that is problematic, because ts-loader does not transpile dependencies. I was doing this myself and had to switch to babel to get the dependencies transpiled once I uncovered the issue with the reliance on Promise.prototype.finally.
If, however, Segment provided a trivial way to specify the implementation of fetch to use (optional, default to current way it is done), then I could trivially plugin my own custom fetch function (I have one that uses a hidden iframe to get a clean fetch function). Alternatively it might be nice to just not have Segment assume it can rely upon the global fetch function or its unfetch fallback because in my case these are adulterated.
I cannot get rid of the third parties. It would be really awesome if I could specify the function to use during init. Then I could keep running Segment in the top frame and get rid of 30-40kb of duplicate polyfill code.
The text was updated successfully, but these errors were encountered:
A secondary request would be to have a trivial way to let the page event enrichment middleware function know to use a different window context. E.g. I would like to specify window.parent to override the default assumption of window. Because right now I have to re-implement the page enrichment plugin by hand (we have many downstream systems already naively relying on the enrichment properties in event context) where I pass in properties from the parent window.
Hey, we are tracking this -- but being able to override the global instance of fetch is very edge-casey (if you can't rely on global fetch, you're in a pretty dicy/unstable environment since it would break things like device mode destinations and many many scripts).
I am in a tight spot where I have to do a very strange setup in the browser. I have to embed segment within an iframe so as to ensure its globals are not messed with. There are multiple other third parties messing with globals, e.g. polyfills, hooked fetch function, incorrectly hooked functions, etc. In particular there is one strange third party hook that assumes that when the global identifier fetch exists that Request and friends also exist, which is not always the case in old browsers.
Embedding in an iframe is not ideal. I have 30kb of polyfill code in the top frame, and now I have to duplicate this polyfill code into the iframe. In particular, I have to do things like polyfill Promise.prototype.finally, which Segment uses but is not well supported in older browsers (e.g. Safari 10). I noticed that Segment is building with ts loader in one of examples, and that is problematic, because ts-loader does not transpile dependencies. I was doing this myself and had to switch to babel to get the dependencies transpiled once I uncovered the issue with the reliance on Promise.prototype.finally.
If, however, Segment provided a trivial way to specify the implementation of fetch to use (optional, default to current way it is done), then I could trivially plugin my own custom fetch function (I have one that uses a hidden iframe to get a clean fetch function). Alternatively it might be nice to just not have Segment assume it can rely upon the global fetch function or its unfetch fallback because in my case these are adulterated.
I cannot get rid of the third parties. It would be really awesome if I could specify the function to use during init. Then I could keep running Segment in the top frame and get rid of 30-40kb of duplicate polyfill code.
The text was updated successfully, but these errors were encountered: