-
Notifications
You must be signed in to change notification settings - Fork 80
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
feat: [FC-0070] listen to xblock interaction events #1431
base: master
Are you sure you want to change the base?
feat: [FC-0070] listen to xblock interaction events #1431
Conversation
Thanks for the pull request, @PKulkoRaccoonGang! What's next?Please work through the following steps to get your changes ready for engineering review: 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. 🔘 Let us know that your PR is ready for review:Who will review my changes?This repository is currently maintained by Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:
When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
42da735
to
cc25c40
Compare
89ba553
to
d9da128
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1431 +/- ##
==========================================
+ Coverage 92.91% 93.09% +0.17%
==========================================
Files 1065 1079 +14
Lines 20979 21175 +196
Branches 4537 4554 +17
==========================================
+ Hits 19493 19712 +219
+ Misses 1419 1391 -28
- Partials 67 72 +5 ☔ View full report in Codecov by Sentry. |
Sandbox deployment failed 💥 |
Sandbox deployment successful 🚀 |
Sandbox deployment successful 🚀 |
Sandbox deployment successful 🚀 |
0c8c37e
to
54c22f2
Compare
Sandbox deployment failed 💥 |
ℹ️ [inform]: In the next PRs we will move away from receiving updated data via iframe reloading. |
Sandbox deployment successful 🚀 |
b34f1f5
to
9c498fd
Compare
Sandbox deployment failed 💥 |
9c498fd
to
a18a2e9
Compare
Sandbox deployment failed 💥 |
Sandbox deployment successful 🚀 |
9a07af9
to
1d9ac29
Compare
[inform]: The following PRs will add:
|
@@ -249,12 +246,7 @@ export function duplicateUnitItemQuery(itemId, xblockId) { | |||
dispatch(showProcessingNotification(NOTIFICATION_MESSAGES.duplicating)); | |||
|
|||
try { | |||
const { locator } = await duplicateUnitItem(itemId, xblockId); | |||
const newCourseVerticalChildren = await getCourseVerticalChildren(itemId); | |||
dispatch(duplicateXBlock({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[inform]: since we use legacy functionality to store xblock data, in the current implementation it makes sense to use thunks exclusively for working with the backend API, without storing data from the Redux store
// to ensure the iframe content is properly refreshed. | ||
setTimeout(() => { | ||
sendMessageToIframe(messageTypes.refreshXBlock, null); | ||
}, 1000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[inform]: such delays will be removed after optimization of updating content inside the iframe, via the backbone.js
setTimeout(() => { | ||
sendMessageToIframe(messageTypes.refreshXBlock, null); | ||
}, 1000); | ||
}, [sendMessageToIframe]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[inform]: we plan to abandon such reboots after implementing the tree comparison algorithm on the backbone.js side
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would that look like? I generally think we need to try to dramatically reduce the amount of code we have on the backbone side, not add major new functionality to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We assumed there might be a comparison algorithm that compares the response containing xblocks information with the current backbone xblocks model. However, this idea turned out to be incorrect since we do not have separate models for xblocks on the backbone side. At the moment, a draft of a working solution is presented in these draft PRs.
Sandbox deployment successful 🚀 |
Sandbox deployment failed 💥 |
9f2796e
to
310421d
Compare
Sandbox deployment failed 💥 |
src/constants.js
Outdated
@@ -76,3 +76,7 @@ export const REGEX_RULES = { | |||
specialCharsRule: /^[a-zA-Z0-9_\-.'*~\s]+$/, | |||
noSpaceRule: /^\S*$/, | |||
}; | |||
|
|||
export const IFRAME_FEATURE_POLICY = ( | |||
'microphone *; camera *; midi *; geolocation *; encrypted-media *, clipboard-write *' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned this on another PR, but this contains a typo: openedx/frontend-app-learning#1500
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[inform] Implemented in follow-up commit: ea4da9f#diff-8e3b187293d8e7902d08eff3c650466860fe527b0c7da8ec32c1ee4a450f97c5R81
setTimeout(() => { | ||
sendMessageToIframe(messageTypes.refreshXBlock, null); | ||
}, 1000); | ||
}, [sendMessageToIframe]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would that look like? I generally think we need to try to dramatically reduce the amount of code we have on the backbone side, not add major new functionality to it.
const [isConfigureModalOpen, openConfigureModal, closeConfigureModal] = useToggle(false); | ||
const { setIframeRef, sendMessageToIframe } = useIframe(); | ||
const [currentXBlockId, setCurrentXBlockId] = useState<string | null>(null); | ||
const [currentXBlockData, setCurrentXBlockData] = useState<any>({}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please specify an actual type, not any
.
What is the "current XBlock" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[inform] Implemented in follow-up commit: ea4da9f#diff-b3b994409f1cdaa22d4d3c9cdba42318405a2bcaf82c1f91056eca6443f7448aR39
return () => { | ||
window.removeEventListener('message', handleMessage); | ||
}; | ||
}, [dispatch, blockId, courseVerticalChildren, currentXBlockId, currentXBlockData]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Complex objects like courseVerticalChildren
and currentXBlockData
sometimes cause additional runs of the effect, because they're compared by reference and not by value. That may be OK in this case but it's not ideal.
This is also missing dependencies like handleDuplicateXBlock
, handleRefetchXBlocks
, etc. which are also changing.
Since currentXBlockData
is React state, I would personally just fetch it inside handleDuplicateXBlock
(const handleDuplicateXBlock = useCallback(() => { /* do something with currentXBlockData */ }, [currentXBlockData]);
) and then you can simplify this so it's just [messageTypes.duplicateXBlock]: () => handleDuplicateXBlock
and only depends on handleDuplicateXBlock
, not directly depending on currentXBlockData
But as I mentioned on the other PR, I think it would be much cleaner to pass in the usage key as part of the event payload, and then you don't need currentXBlock[Id|Data]
at all, and you can simplify a lot of these, as well as removing most of the dependencies for the useEffect
and useCallback
hooks, which will improve performance and reduce re-rendering a lot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thanks. I like the idea of getting the xblock id
via payload
. I added this feature + did some refactoring, please take a look.
ea4da9f
Sandbox deployment successful 🚀 |
2261a51
to
4c2d5bf
Compare
4c2d5bf
to
ea4da9f
Compare
Sandbox deployment successful 🚀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for that change, @PKulkoRaccoonGang. I think that's much cleaner.
I haven't tested this again but I'm happy with how the code is looking. Thanks for all the new Typescript typing 💯
Sandbox deployment successful 🚀 |
🚨 Dependencies:
Xblock interaction events
Description
This PR includes changes to the CourseUnit component and the functionality of interaction between xblocks in the iframe and the react page.
The following events have been processed:
Testing instructions
Screen.Recording.2024-11-15.at.15.52.27.mov
Settings