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

Add hot reload #26

Merged
merged 23 commits into from
Jul 10, 2024
Merged

Add hot reload #26

merged 23 commits into from
Jul 10, 2024

Conversation

bb-face
Copy link
Collaborator

@bb-face bb-face commented Jun 20, 2024

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

src/App.js Outdated

const SESSION_STORAGE_REDIRECT_MAP_KEY = 'nearSocialVMredirectMap';
export const SESSION_STORAGE_REDIRECT_MAP_KEY = "nearSocialVMredirectMap";
Copy link
Contributor

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

@@ -0,0 +1,3 @@
import { createContext } from "react";

export const HotReloadContext = createContext(false);
Copy link
Contributor

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".

Copy link
Collaborator

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?

Copy link
Collaborator Author

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

@elliotBraem elliotBraem removed their assignment Jun 21, 2024
Copy link
Collaborator

@petersalomonsen petersalomonsen left a 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?

@petersalomonsen
Copy link
Collaborator

Also see my comment here about the redirect map

#20 (comment)

@elliotBraem elliotBraem mentioned this pull request Jun 22, 2024
Copy link
Collaborator

@petersalomonsen petersalomonsen left a 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?

useEffect(() => {
(async () => {
if (hotReload) {
const socket = io(process.env.BOS_LOADER_WS || "ws://127.0.0.1:8080", {
Copy link
Collaborator

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.

Copy link
Collaborator Author

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
@elliotBraem
Copy link
Contributor

bos-workspace is ready to support this:

NEARBuilders/bos-workspace#118

Copy link
Collaborator

@petersalomonsen petersalomonsen left a 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.

@elliotBraem elliotBraem mentioned this pull request Jul 2, 2024
4 tasks
@elliotBraem
Copy link
Contributor

@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 bos-workspace dev -g ./dist instead of yarn start

@petersalomonsen
Copy link
Collaborator

@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 bos-workspace dev -g ./dist instead of yarn start

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?

@petersalomonsen
Copy link
Collaborator

@bb-face @elliotBraem I read this again, and maybe I missed your point. Replacing the http-server with bos-workspace dev -g ./dist will probably give you the websocket served from the same port as you suggest. But it would still be good to have the test in this repo, since it feels a bit wrong to have functionality in here that we don't know how to test automatically.

@bb-face
Copy link
Collaborator Author

bb-face commented Jul 7, 2024

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!

@elliotBraem
Copy link
Contributor

elliotBraem commented Jul 8, 2024

@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:

 {
    {
      dev: {
        hotreload: {
          enabled: true,
          wss: "wss://localhost:3001",
        },
      },
      features: {
        enableComponentSrcDataKey: true,
        commitModalBypass: {
          authorIds: ["mob.near", "root.near"],
          sources: [
            "cool.near/widget/CoolComponent",
            "awesome.near/widget/AwesomeComponent",
          ],
        },
        bypassTransactionConfirmation: true
        enableWidgetSrcWithCodeOverride: true
      },
      defaultFinality: undefined
    }
  }

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.

@elliotBraem
Copy link
Contributor

This has been updated to use the config object with a test that confirms a working hot reload via socket server

@elliotBraem elliotBraem merged commit a3958f1 into main Jul 10, 2024
1 check passed
@elliotBraem elliotBraem deleted the add-hot-reload branch July 10, 2024 23:48
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.

3 participants