Skip to content
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

Corrects an invalid react JSX issue #2

Conversation

valadas
Copy link

@valadas valadas commented Sep 23, 2020

Corrects an invalid react JSX issue

@mitchelsellers mitchelsellers merged commit f35d010 into mitchelsellers:fix/RemoveImprovement Sep 23, 2020
@valadas valadas deleted the Fix/RemoveImprovement branch April 14, 2022 21:44
mitchelsellers pushed a commit that referenced this pull request Sep 21, 2022
Closes dnnsoftware#5262

It was a bit of a rabbit hole to go down to figure this one out. Initially I thought the CDF had an error serving javascript with a css mime type. But the underlying issue is that with Stencil.js there is a main script that registers individual components scripts in a different way depending on browser support and loads or not some polyfills accordingly (very efficient). This means that that "entry" file was served by the CDF but the file attempts to load it's "component details" files relative to that path. Unfortunatelly thanks to CDF, that relative path was the CDF handler itselft instead of the path to the other js files. And the CDF defaults to css mime type if it can't figure out the right one.

The Client Dependency Framework does not support javascript modules (because of script relative paths) and there are no plans to add such support according to their repository. Also with this modern way of lazy-loading and with modern http2 having compression and multiplexing, bundling those files is actually a performance hit and not recommended.

Which left us with a couple options:
1. Not take advantage of Js modules by bundling all js files (but this compile target was deprecated by Stencil for the reasons above), so it would have taken quite some time and incur a performance hit instead of a boost.
2. Not use CDF for this project, but this was broken if hosting in a virtual directory (IIS Application under an IIS site folder).

This PR implementes #2 but adds support for ApplicationPath to the existing Request SPA token. This new token support can also be very useful for other SPA modules.

So under normal hosting, this returns `/` but if the site is hosted in a dnn subdirectory it will return '/dnn' (or whataver the web path is for that web application.

I think this will cover all scenarios here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants