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
Add support for cross-domain Apps #270
Comments
Alternately, '//myawesomeapp.com' for a protocol-less request |
similar to #73 ? |
Looks like #73 is tagged with version2. I could be wrong, but I don't think this would necessarily be a breaking change. |
Specifically for this issue (slightly different from #73), here is some pseudo and real code from my own testing that will support this. I'm doing this in a local example where I'm simply modifying the manifest request before it's sent:
In turn, you can then reference this Url in the app's requests which would otherwise be hardcoded or relative:
|
close in favor of #73 |
When working with apps loaded cross-domain into a container, one of the common challenges encountered is that any relative paths in the app are executed in the scope of the container, and cannot be found. It would be great to see an addition to perhaps context, or the overall manifest of an app, allowing the app to declare its own FQDN, such that the app itself could later reference this parameter, and make appropriate requests for additional assets or JSON data.
The only known workaround for this at present is to hardcode FQDNs into the apps themselves, which is less than ideal from a build pipeline and deployment pov.
Reference example on a possible solution (see appBaseUrl param listed below):
The text was updated successfully, but these errors were encountered: