-
Notifications
You must be signed in to change notification settings - Fork 6
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 hot reload #26
Add hot reload #26
Conversation
src/App.js
Outdated
|
||
const SESSION_STORAGE_REDIRECT_MAP_KEY = 'nearSocialVMredirectMap'; | ||
export const SESSION_STORAGE_REDIRECT_MAP_KEY = "nearSocialVMredirectMap"; |
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.
Let's move this to useRedirectMap rather than exporting
src/contexts/hotReloadContext.js
Outdated
@@ -0,0 +1,3 @@ | |||
import { createContext } from "react"; | |||
|
|||
export const HotReloadContext = createContext(false); |
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.
Since this is all this is, what if we cleaned it up some -- we could combine hooks/useRedirectMap and contexts/hotReloadContext
maybe into utils/RedirectMap? or dev-tools/RedirectMap?
This could export the useRedirectMap hook, and export a RedirectMapProvider (instead of doing </HotReloadContext.Provider> in App.js) -- and have it take "enableHotReload" as a prop instead of "value".
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, shouldn't hot reload be configurable in some other way than directly in the source here? With this approach, how can hot-reload be configured when using the near-bos-webcomponents npm package?
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.
@elliotBraem I tackle your comment in the last commit: 4eff901
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.
Quite a bit of changed formatting of the code, without any real changes. And also added lines with comments. A bit confusing when reviewing and trying to find the actual change.
Would it be possible to make the diff a bit clearer on what has actually changed?
Also see my comment here about the redirect map |
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.
Would it be possible to add a test for triggering the hot reload?
src/utils/redirectMap.js
Outdated
useEffect(() => { | ||
(async () => { | ||
if (hotReload) { | ||
const socket = io(process.env.BOS_LOADER_WS || "ws://127.0.0.1:8080", { |
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.
Is process.env
available here in the browser context?
Also, must it be only 127.0.0.1? If developing in github codespaces, you get dedicated host names with https.
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.
Fixed in this commit: e1af6c4
test structure WIP: websocket test WIP: hot realod websocket test Remove test
bos-workspace is ready to support this: |
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 also need the test for hot reload to ensure that what is implemented here will not be broken by someone else later. Also we need the test as a demonstration for how the hot reload works, and as a guide on how to use it.
@petersalomonsen yeah, good point on a test for validating hot reload. Since the socket server for hot reload needs to be on the same port as the app, it's been difficult to write a test for this -- we've tried mocking web socket or proxying requests, but it was challenging -- I'm not sure, @bb-face may have gotten closer to figuring it out? Regardless, I'm wondering if this test belongs in bos-workspace repository instead? Or maybe we should update this playwright webServer command to use |
yeah, this project does not have a dev-server ( and it was never the intention either), but bos-workspace does have that Is we want to build a development environment like bos-workspace in near-bos-webcomponent, then we should also introduce a server for serving the components and a websocket for hot reload. The main purpose of this project is to be able to serve BOS content inside a custom element in any web page ( not just React apps ). It's hard to introduce hot-reload without actually also taking over the role that bos-workspace has as a dev server. So not sure what was the intention behind introducing hot-reload here? |
@bb-face @elliotBraem I read this again, and maybe I missed your point. Replacing the |
Hey @petersalomonsen! Thanks for the feedback, I just pushed a working test that in my opinion makes sure that hot-reload is works properly, let me know what do you think! The only problem left to fix is the port, unfortuntaely I couldn't find a way to leave the socket server run (during the test) on the same port as the web application but it's a requirement...if you have any suggestions they are more than welcomed! |
@bb-face, let's move this "enablehotreload" feature into a more generic attribute named "config". This generic attribute can support hot reload as well as other features we may want to configure in the futre, such as "enableComponentSrcDataKey", "defaultFinality", "commitModalBypass", "bypassTransactionConfirmation" which are all used by the VM and we may want to support on this roadmap. For example:
I am in no way attached to this structure, but notice how hot reload has a customizable source, which we can use with the existing test -- otherwise it defaults to the same port. Don't implement the other features, only hot reload support. |
This has been updated to use the config object with a test that confirms a working hot reload via socket server |
PR for the issue: #20
Videos of the test:
redirectmap-hot-reload-If-enablehotreload-is-true-an-api-request-to-websocket-io-will-be-triggered-chromium.mp4
redirectmap-session-storage-Should-be-possible-to-provide-a-redirectmap-through-session-storage-key-chromium.mp4
redirectmap-hot-reload-If-enableHotReload-is-false-there-will-be-no-api-request-to-socket-io--chromium.mp4
redirectmap-bos-loader-url-Should-be-possible-to-provide-a-redirectmap-through-flags-in-localStorage-chromium.mp4