Adapting calendar to use a non-remote environment #1018
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue
Closes #889
Context / Background
Just like #887, this time for the calendar part.
"In #646 we are trying to update electron to the newest version, but we're blocked because we're using electron remote, and that is deprecated in the newest versions."
What change is being introduced by this PR?
In this patch I adapt the Calendar window to work through a preload script, and an isolated environment, without any node module dependencies outside of what the preload API offers.
Basically, I exposed an API on the new files renderer/preload-scripts/calendar-api.js and calendar-bridge.js using the ContextBridge electron object (see https://www.electronjs.org/docs/latest/api/context-bridge). This API is defined via the main process, and is set to the global window object, and can be accessed in the calendar.js file, loaded in a BrowserWindow, inside a new renderer process.
How will this be tested?
Same as before. Manual tests also were executed.