How to integrate this into non-browser environments?

[shirakaba]

I tried integrating this for my custom React renderer which uses a JS environment more similar to Node (e.g. uses global rather than window). After I aliased global as window, it got stumped by the lack of an addEventListener API:

file: node_modules/@pmmmwh/react-refresh-webpack-plugin/src/runtime/errorEventHandlers.js:85:10: JS ERROR TypeError: global.addEventListener is not a function. (In 'global.addEventListener(eventType, eventHandler)', 'global.addEventListener' is undefined)

What are the browser dependencies, and can anything be done to decouple it from the browser?

[pmmmwh]

What are the browser dependencies, and can anything be done to decouple it from the browser?

As of now, the core of plugin depends only on the location API (window.location) for reload functionality (and socket routing, if you're using WDS). The error overlay integration further depends on window.addEventListener and window.removeEventListener (and DOM APIs for rendering), because we listens on the error and the unhandledrejection events.

I'm not sure about your use case, but in reality you could disable the error overlay integration or use a custom error overlay setup to correctly wire up error-like events listening (only on 0.3.0). For the part related to the location API, I'm working on a feature to not force reload when unaccepted updates happen, so after that lands we should be somehow decoupled from the browser.

[pmmmwh]

Can anything be done to decouple it from the browser?

@shirakaba
I've read a bit on the Node.js process API and it seems that the uncaughtExceptionMonitor event would cover what an error overlay requires. However, I'm not sure if that's something that is generally available for custom JS-based renderers. Would like your thoughts before I take any further action.

[dangreen]

@pmmmwh in dev environment with ssr this plugin cause the error ReferenceError: window is not defined

[pmmmwh]

@pmmmwh in dev environment with ssr this plugin cause the error ReferenceError: window is not defined

Can you provide more background information, like where the error originates, whether the plugin is applied for the server bundle, etc.?

Also, see #36 for some solutions others have figured out.

[shirakaba]

@pmmmwh Sorry for disappearing! Another project has taken up my full attention for the last month, but it should be finished in a few weeks, after which time I can dedicate more attention back to this.

Thank you very much for responding with details. I'll answer a few things now:

As of now, the core of plugin depends only on the location API (window.location) for reload functionality (and socket routing, if you're using WDS).

Do you mean specifically just window.location.reload(), or a few other things as well? I'd have to research what the NativeScript equivalent would be (will likely involve interrogating the core team). Might have something to do with View.prototype._handleLivesync and global.__onLiveSync.

I've read a bit on the Node.js process API and it seems that the uncaughtExceptionMonitor event would cover what an error overlay requires.

I presume here we're talking about the runtime running the app, rather than the runtime running Webpack?

The JS context in NativeScript apps doesn't implement (the majority of) the Node.js APIs, for example process. NativeScript uses forks of both JavaScriptCore (for iOS) and V8 (for Android; but will soon be used for iOS instead of JSC).

NativeScript seems to have the following approach (copied below). I think it applies equally to both JS errors and native errors:

var application = require("application");

application.on(application.uncaughtErrorEvent, function (args) {
    if (args.android) {
        // For Android applications, args.android is an NativeScriptError.
        console.log("NativeScriptError: " + args.android);
    } else if (args.ios) {
        // For iOS applications, args.ios is NativeScriptError.
        console.log("NativeScriptError: " + args.ios);
    }
});

[pmmmwh]

Do you mean specifically just window.location.reload(), or a few other things as well?

Specifically just window.location.reload() - that's the "de-facto" way of bailing out of HMR updates in the Webpack ecosystem for the browser. I'm not sure if this concept translates to the native world though.

In the next version I should be able to not bail out by default (in fact, there's only a single call to window.location.reload() now left in the code base).

I presume here we're talking about the runtime running the app, rather than the runtime running Webpack?

Yup. I think for your case, you'll have to either implement a custom error overlay integration or disable it (Are DOM APIs available in NativeScript?).

I think it would look something like this (I only skimmed through the docs so this might not work):

import * as ErrorOverlay from '@pmmmwh/react-refresh-webpack-plugin/src/overlay';
import * as application from 'tns-core-modules/application';

// Copy everything from './src/runtime/ErrorOverlayEntry.js',
// except the lines calling `registerSomethingHandler`.

application.on(application.uncaughtErrorEvent, (args) => {
    ErrorOverlay.handleRuntimeError(args.error);
});

Or maybe even better, if you use trace.error everywhere for errors:

import * as ErrorOverlay from '@pmmmwh/react-refresh-webpack-plugin/src/overlay';
import * as traceModule from 'tns-core-modules/trace';

// Copy everything from './src/runtime/ErrorOverlayEntry.js',
// except the lines calling `registerSomethingHandler`.

const errorHandler: traceModule.ErrorHandler = {
  handlerError(error) {
    traceModule.write(err, 'unhandled-error', type.error);
    ErrorOverlay.handleRuntimeError(error);
  },
}

traceModule.setErrorHandler(errorHandler);

[shirakaba]

Specifically just window.location.reload() - that's the "de-facto" way of bailing out of HMR updates in the Webpack ecosystem for the browser. I'm not sure if this concept translates to the native world though.

When you say "bailing out of HMR updates", are you referring to the case when a hot update cannot practically be applied, so the best response available is to restart the app afresh and load in the latest bundle? Thus, on web, window.location.reload() fits that role?

If so, I'll have to ask what the closest equivalent is to that in NativeScript. In React Native, it's surely the action that happens when you force a reload of the JS bundle, but NativeScript doesn't to my knowledge have something like that (at least not so conveniently) yet.

Yup. I think for your case, you'll have to either implement a custom error overlay integration or disable it (Are DOM APIs available in NativeScript?).

NativeScript doesn't implement HTML Elements like <div>, nor does it implement DOM – but React NativeScript does implement (has borrowed from NativeScript Vue, actually) a DOM interface, so it conforms to the DOM model and implements Elements. So we're missing things like document and window but we've got things like element.addEventListener.

I'm sure the task of translating the error overlay to React NativeScript won't be a show-stopper 🙂 NativeScript does at least implement CSS and flexbox.

I think it would look something like this (I only skimmed through the docs so this might not work):

Thank you very much for these code snippets (and even diving into the NativeScript codebase)! That's an enormous help. I haven't actually tried using the trace module myself yet (though I've seen it being used in NativeScript Vue), but it may indeed be a better fit than application.uncaughtErrorEvent. I'll look into both of them and assess which one makes more sense.

So it seems like the path forward would be:

1. For an initial sanity test, disable the error overlay altogether and check whether React NativeScript hits any other obstacles at runtime;
2. Determine a NativeScript equivalent to window.location.reload and polyfill that. Again, for an initial sanity test, I could just throw an obvious error to kill the app and force it to restart;
3. Port ErrorOverlay to React NativeScript, and invoke it upon uncaught/unhandled errors.

In the next version I should be able to not bail out by default (in fact, there's only a single call to window.location.reload() now left in the code base).

Would it be possible to expose an option for providing one's own implementation of reload (rather than having to create a shim that clobbers window.location.reload())?

Also: I'm not sure how to provide a custom ErrorOverlay to the React Refresh plugin. I can see that the plugin (I guess we're talking about the Webpack plugin rather than the Babel plugin?) accepts an options object, and that it has an options.overlay field...

... But as it's Node.js reading and running webpack.config.js and constructing the React Refresh plugin instance, how is my React NativeScript implementation of ErrorOverlay (which can only run in a NativeScript environment, not a Node.js environment) supposed to be passed in?

It's likely I'm missing some piece of logic..!

[pmmmwh]

Determine a NativeScript equivalent to window.location.reload and polyfill that. Again, for an initial sanity test, I could just throw an obvious error to kill the app and force it to restart;

Would it be possible to expose an option for providing one's own implementation of reload (rather than having to create a shim that clobbers window.location.reload())?

After #104 lands the call to window.location.reload() will be eliminated altogether, so you can skip these steps too.

How is my React NativeScript implementation of ErrorOverlay (which can only run in a NativeScript environment, not a Node.js environment) supposed to be passed in?

You can write it as if it is in a NativeScript environment - the implementation will be injected via webpack.ProvidePlugin in the resulted bundle so it will only run with the bundle.

[shirakaba]

After #104 lands the call to window.location.reload() will be eliminated altogether, so you can skip these steps too.

That's brilliant! Thanks so much 🙇‍♂️

You can write it as if it is in a NativeScript environment - the implementation will be injected via webpack.ProvidePlugin in the resulted bundle so it will only run with the bundle.

That seems like magic! Will I even be able to make imports (I'll need to build the UI using imports such as import { FlexboxLayout } from "@nativescript/core";) in my implementation of ErrorOverlay? Just that I haven't used ProvidePlugin before.

[pmmmwh]

That seems like magic! Will I even be able to make imports (I'll need to build the UI using imports such as import { FlexboxLayout } from "@nativescript/core";) in my implementation of ErrorOverlay?

Yes, it should "just-work" like any other code you write.

Edit: Also, #104 has landed in v0.4.0-beta.2.

[shirakaba]

@pmmmwh Awesome, sounds like all the ingredients are there for it to work. It might be a few weekends before I'm free to try integrating it again (or maybe I'll even find a moment this weekend), but I'll certainly report back once I've tried! Thanks for your thorough response and timely refactors!

[shirakaba]

@pmmmwh I've come back to this and have installed version 0.4.0-beta.2. Here's the error I get upon my Webpack build:

file:///app/bundle.js:4367:13: JS ERROR ReferenceError: Can't find variable: $RefreshReg$
at ./testComponents/navigation.tsx(file:///app/bundle.js:4397:34)
at __webpack_require__(file: app/webpack/bootstrap:770:0)
at fn(file: app/webpack/bootstrap:120:0)
at file: app/testComponents/AppContainer.tsx:1:0
at ./testComponents/AppContainer.tsx(file:///app/bundle.js:3254:34)
at __webpack_require__(file: app/webpack/bootstrap:770:0)
at fn(file: app/webpack/bootstrap:120:0)
at file: app/app.ts:1:31
at ./app.ts(file:///app/bundle.js:3139:34)
at __webpack_require__(file: app/webpack/bootstrap:770:0)
at fn(file: app/webpack/bootstrap:120:0)
at file:///app/bundle.js:4405:37
at __webpack_require__(file: app/webpack/bootstrap:770:0)
at checkDeferredModules(file: app/webpack/bootstrap:43:0)
at webpackJsonpCallback(file: app/webpack/bootstrap:30:0)
at anonymous(file:///app/bundle.js:2:61)
at evaluate([native code])
at moduleEvaluation([native code])
at [native code]
at asyncFun<…>

Here's my webpack config, on the branch fast-refresh: react-nativescript.webpack.config.js. It inherits from (and overrides) this webpack.config.js. Sorry for the complexity (that's the way NativeScript webpack configs are).

Possibly related issues:
#92
#36

And PR:
#102.

In #92, with regards to a similar error for $RefreshSig$, you mentioned:

My guess is that you've included the react-refresh/babel plugin to process node_modules. This will break because some code (as used by Webpack and WDS) will inevitably run before the plugin.

However, in my case I have excluded node_modules in my rule using babel-loader.

Do you have any ideas what could be the problem here?

[shirakaba]

Update: by adding these aliases with DefinePlugin, I was able to squash that error. The app now builds and runs! 🥳

new webpack.DefinePlugin({
    "window": "global.global",
    "process.env.NODE_ENV": JSON.stringify(production ? "production" : "development"),
})

However, even though changes are detected and updates applied (I believe by HotModuleReplacementPlugin), the component on-screen does not visually update.

Webpack compilation complete. Watching for file changes.
Webpack build done!
Successfully transferred bundle.86e97e9f3df714734087.hot-update.js on device 57DE46EC-8E05-41EF-964C-AF0686B7586B.
Successfully transferred 86e97e9f3df714734087.hot-update.json on device 57DE46EC-8E05-41EF-964C-AF0686B7586B.
Refreshing application on device 57DE46EC-8E05-41EF-964C-AF0686B7586B...
CONSOLE INFO file: node_modules/nativescript-dev-webpack/hot.js:3:0: HMR: Checking for updates to the bundle with hmr hash 86e97e9f3df714734087.
CONSOLE INFO file: node_modules/nativescript-dev-webpack/hot.js:3:0: HMR: The following modules were updated:
CONSOLE INFO file: node_modules/nativescript-dev-webpack/hot.js:3:0: HMR:          ↻ ./testComponents/navigation.tsx
CONSOLE INFO file: node_modules/nativescript-dev-webpack/hot.js:3:0: HMR: Successfully applied update with hmr hash 86e97e9f3df714734087. App is up to date.
Successfully synced application uk.co.birchlabs.rnssample on device 57DE46EC-8E05-41EF-964C-AF0686B7586B.

When I was using React Hot Loader, that console output would have been considered healthy and would have led to visual updates. What might be the problem here?