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

[SE-4650] OEP-15 - add support for course-wide custom resources #581

Closed
wants to merge 2 commits into from

Conversation

ha-D
Copy link

@ha-D ha-D commented Aug 11, 2021

Description

Details about the purpose of this PR can be found in edx-platform#28411.

In this PR we're just taking the course-wide JS and CSS URLs from the course metadata and adding them to then pager <head>.

Testing Instructions

  • Run a devstack and checkout both edx-platform and frontend-app-learning repo to the hadi/se-4650/oep-15 branch
  • Follow the testing instructions edx-platform#28411 to add course-wide scripts to the course via the studio
  • Visit a course page, check that the scripts are added to the page head

(If there's a simple way for me to get the Learning MFE running on the OCIM sandbox in edx-platform#28411 let me know and I could do that instead, I didn't want to spend too much time seeing whether I could do that or not)

Reviewers

@edx/engage-squad

@openedx-webhooks openedx-webhooks added needs triage open-source-contribution PR author is not from Axim or 2U labels Aug 11, 2021
@openedx-webhooks
Copy link

openedx-webhooks commented Aug 11, 2021

Thanks for the pull request, @ha-D! I've created OSPR-5960 to keep track of it in JIRA, where we prioritize reviews. Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

  • supporting documentation
  • Open edX discussion forum threads
  • timeline information ("this must be merged by XX date", and why that is)
  • partner information ("this is a course on edx.org")
  • any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

Copy link

@nizarmah nizarmah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @ha-D! Nice work on this as well. 👍🏼

I've read through the changes and I have a small nit.

Other than that, I'm building a new app server for the sandbox instance where the frontend-app-learning MFE is enabled.

I'll update my review once the new app server is ready for me to test.

@@ -46,6 +48,8 @@ function LoadedTabPage({
<>
<Helmet>
<title>{`${activeTab ? `${activeTab.title} | ` : ''}${title} | ${getConfig().SITE_NAME}`}</title>
{courseWideJs && courseWideJs.map(js => <script key={js} src={js} />)}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nit: would you mind please adding the script type, type="text/javascript"?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link

@nizarmah nizarmah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ha-D thanks for addressing the comment I had 👍🏼 I've setup the frontend-app-learning MFE on the sandbox instance.

I've also tested that things are working as expected there as well.

I had some trouble with the toastr library. I didn't end up investigating it; instead, I added an alert dialog.

LGTM though. I'll pass the review over to @bradenmacdonald.

@natabene
Copy link

@ha-D Thank you for your contribution. Please let me know once it is ready for our review.

@openedx-webhooks openedx-webhooks added waiting on author PR author needs to resolve review requests, answer questions, fix tests, etc. and removed needs triage labels Aug 18, 2021
@bradenmacdonald
Copy link
Contributor

@natabene I think this is ready for review now, see comment above.

Although I was asked to review, I'm not a core committer on this repo nor super up to speed with it, so I think we'll need you to find us a reviewer.

The code seems simple and straightforward though :)

@natabene
Copy link

@BbrSofiane Would you like to review as a core committer for frontend-app-learning?

Comment on lines +51 to +52
{courseWideJs && courseWideJs.map(js => <script key={js} type="text/javascript" src={js} />)}
{courseWideCss && courseWideCss.map(css => <link key={css} rel="stylesheet" href={css} />)}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm very leery of adding arbitrary css/js to the react side of things. The MFE is fast moving and doesn't want to have to make guarantees about DOM structure or anything like that.

For example, when we added the course-welcome and course-handouts features to the MFE, we "sandboxed" that arbitrary html/js inside iframes.

Can we do this asset loading inside the courseware iframe, to better isolate it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I'm sorry - I'm reading the part of the platform PR that says this is explicitly your point - you want them in the parent page too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm chatting with folks that are bigger frontend experts at edX - but this whole arbitrary JS approach is very much not where we are trying to heading with the MFEs. I'm trying to see what the vision for this kind of use case is.

And your use case is basically loading some external libraries that do page-wide stuff, not trying to manipulate any specific DOM structures, yeah? Because that would definitely be a problem, given how React works.

But maybe we can find a more future-proof way to inject external libraries...

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mkikix Glad to demo some of our use cases if it would help.

Copy link

@jmyatt jmyatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we will not be able to approve this approach. As @mikix mentioned, this works around a core edX MFE principle of sound boundary definitions.

@ha-D
Copy link
Author

ha-D commented Aug 25, 2021

All right, thats understandable. We can assume the Course-wide JS/CSS should only be targeted towards the XBlocks and course material (which is handled in this PR) and not the MFE.

As for use cases, I can think of a couple examples where having something like this in the MFE would have been useful to clients:

  • Adding things like chatbots to all pages
  • Adding a client's preferred analytics service to their OpenEdx deployment

@openedx-webhooks openedx-webhooks added engineering review and removed waiting on author PR author needs to resolve review requests, answer questions, fix tests, etc. labels Sep 2, 2021
@bradenmacdonald
Copy link
Contributor

@ha-D @jmyatt What about changing this approach to only add the JS within the iframe? Surely having that use case is better than nothing, and then there's no interference with React.

And it provides similar capabilities to the current situation, which sees authors doing things like adding HTML blocks (with the custom JS) to every unit - which has the same effect but is a giant pain to manage.

@ha-D
Copy link
Author

ha-D commented Sep 2, 2021

@bradenmacdonald Yeah I agree, it's what I intended as well. It wouldn't need any changes on the MFE side though, the content rendered in the iframes should already have the JS included with the changes in the edx-platform PR, since it's using the same base templates that were changed there.

@mikix
Copy link
Contributor

mikix commented Sep 2, 2021

Yeah from an MFE perspective, loading the JS in the xblock iframe seems fine - that's similar to existing patterns and security boundaries.

I think medium to long term, there might need to be a discussion around a modern version of OEP-15. But in the meantime, having this JS loaded inside the xblock iframe seems reasonable (and isn't anything adding any new risk, right? - course teams can inject arbitrary JS via html xblocks - this is just a super easy way to do it across the course, yeah?)

Which would mean we can close this MFE-side PR?

@Colin-Fredericks
Copy link

having this JS loaded inside the xblock iframe seems reasonable (and isn't anything adding any new risk, right? - course teams can inject arbitrary JS via html xblocks - this is just a super easy way to do it across the course, yeah?)

@mikix That's correct - this will replicate existing functionality but with a centralized file reference. Not as useful as the original proposal, but still an improvement.

Presumably we'll have to keep adding JS to custom tabs by hand, unless those are secretly XBlocks these days. At least that's fewer files.

We used to be able to access the outer frame for the course, but the "new user experience" broke that and we had to pull a bunch of course navigation walkthroughs.

@natabene
Copy link

natabene commented Sep 8, 2021

Owning team believes that, unfortunately, the only thing to do with this PR is to close it without merging. That latest comment seems like more of a Product question, and not something that this PR addresses.

@openedx-webhooks
Copy link

@ha-D Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
open-source-contribution PR author is not from Axim or 2U rejected
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants