I am building a React App, initialized with create-react-app.
The strangest thing is happening, on a regular basis, it stops running, and in the sources tab of the chrome developer tools I get this being highlighted:
function handleDisconnect() {
backendDisconnected = true;
window.removeEventListener('message', handleMessageFromPage);
window.postMessage({
source: 'react-devtools-content-script',
payload: {
type: 'event',
event: 'shutdown'
}
}, '*');
} // proxy from the main page to devtools (via the background page)
I have no idea why this is happening. It's never happened in any React apps I have built over the last few years.
My PC is pretty old and slow to the point of struggling sometimes. I am wondering if perhaps the app running on this local environment is just cutting out, as it were. Otherwise, I would have no clue where to start. If it is any help, I am running Video.js inside this app.
I would be very grateful for any pointers.
Related
I'm struggling to find information about properly making notifications with a custom alert sound in Electron. How is it recommended that we do this in both the main and renderer processes?
Here's an example attempt I put in my main process (I know the path is not the issue here) where it plays the default sound anyway:
let exNotification = new Notification({
title: "Example!",
body: "Here's an example!",
silent: false,
sound: path.join(
app.getAppPath(), "assets/ping.mp3"),
});
exNotification.show();
...and even if this did work, it would be MacOS only.
There seems to be a variety of packages for this, but there's nothing definitive I can find that simply says what the "right" way is for working cross-platform.
There's a lot of hacky-feeling suggestions like "make the notification silent and use a different package to play a sound at the same time," or "use this 3rd party notification package that hasn't been updated in a couple years," and I am worried about the long-term viability of those options.
Any advice? What is the "proper" way of doing cross-platform notifications with custom sounds like the big Electron apps do, like Slack or Discord? Would something like Tauri or some other web-app wrapper work better for this that I'm not aware of?
I think that is better if you set the notification as silent and fire a sound from the app.
const sound = require("sound-play");
const exNotification = new Notification({
title: "Example!",
body: "Here's an example!",
silent: true
});
exNotification.show();
sound.play("./{your_path}/assets/ping.mp3");
Also I suggest this module, so you will reproduce the sound only if notifications are allowed for your app.
I'm experiencing an issue in Electron where window.webContents.send() behaves as expected on the first execution, but after I call it again the function runs twice, then three times, etc.
Here's a stripped back example of one of the menubar functions I'm using to tell the renderer to package data for saving.
Main.js
{
label: 'Save',
click() {
window.webContents.send('myChannel', myArgs);
}
}
Renderer.js
ipcRenderer.once('myChannel', (evt, myArgs) => {
// package data for saving
});
My understanding is that Electron is creating a new event handler each time I click save in the menubar. I can't seem to find any documentation on how to dispose the event handler in the electron docs.
Here's a link to a similar problem. The solution isn't of much help to me, as I need these functions to only be run when they're called from the menubar, not when the app first launches.
Thanks!
A bit of an odd one...
I've specified a redirect path for the root index page for one of my projects. It worked no problem and redirected me to the correct path, but now it redirects me to that same path for the root index page for all of my other projects. (trying to visit localhost:3000 now redirects me to localhost:3000/ggp for all of my projects)
I've tried restarting servers, deleting the next.config.js file in the original project, commenting out the redirect key, overriding it with a different path in both the original project and in the other project but all to no avail.
This is the first time I've created a next.config.js file and obviously the first time using the redirect key. I was following the guidance in the docs (https://nextjs.org/docs/api-reference/next.config.js/redirects).
At first I thought it might be because I set permanent to true, but that would seem like a bit of a weird feature to make it global and when I run a different project in dev mode (next dev) and debug, everything works normally as it should. So I'm not sure if the value just got cached on first use or something.
Has anybody encountered this before / know a way of fixing it? I'd appreciate your help!
The original next.js.
module.exports = {
async redirects() {
return [
{
source: '/',
destination: '/ggp',
permanent: true,
},
]
},
}
Turns out the problem was that when you set the permanent key to true, it caches the redirect route in the browser (at least it does in Google Chrome), so that redirect route is used for all requests to that path, regardless of which project is active.
Clearing the browser cache and switching the permanent key to false, solves the issue for me (I just opened up the inspector, went to the network tab, right clicked in the network request table and selected "clear browser cache").
It seems like a weird feature to me, especially since it's use seems pretty ambiguous in the docs (although it may be mentioned somewhere that I haven't looked).
Anyway, lesson learned: Test the issue in another browser before tearing your hair out :')
It is JavaScript based UWP application. Application is listening to checkpoint/resume event as described on MSDN samples. On checkpoint I'm saving state of the application like history.
How can I prevent application from crashing? What would be the exact sequence of events that occur when phone is locked.
on checkpoint:
app.oncheckpoint = function (args) {
try {
args.setPromise(Ax.Utils.delay(1000).then(function (r) {
WinJS.Application.sessionState.history = {}; //json string
return true;
}));
} catch (e) {
}
};
Debugging from Visual studio using Lifecycle state works well.
Wish to add answer to my own question.
Application was crashing due to google ads object included in the stream was not well formed that was causing the app to crash. Such as ads array was not handled correctly during checkpoint.
I've consulted a lot of resources on Service Workers:
Updating your ServiceWorker
ServiceWorker: Revolution of the Web Platform
Jake Archibald's lovely SVGOMG.
However, I can't for the life of me figure out how to update the page after a new ServiceWorker has been installed. No matter what I do, my page is stuck on an old version, and only a hard refresh (Cmd-Shift-R) will fix it. No combination of 1) closing the tab, 2) closing Chrome, or 3) location.reload(true) will serve the new content.
I have a super simple example app mostly based on SVGOMG. On installation, I cache a bunch of resources using cache.addAll(), and I also do skipWaiting() if the current version's major version number doesn't match the active version's number (based on an IndexedDB lookup):
self.addEventListener('install', function install(event) {
event.waitUntil((async () => {
var activeVersionPromise = localForage.getItem('active-version');
var cache = await caches.open('cache-' + version);
await cache.addAll(staticContent);
var activeVersion = await activeVersionPromise;
if (!activeVersion ||
semver.parse(activeVersion).major === semver.parse(version).major) {
if (self.skipWaiting) { // wrapping in an if while Chrome 40 is still around
self.skipWaiting();
}
}
})());
});
I'm using a semver-inspired system where the major version number indicates that the new ServiceWorker can't be hot-swapped for the old one. This works on the ServiceWorker side - a bump from v1.0.0 to v1.0.1 causes the worker to be immediately installed on a refresh, whereas from v1.0.0 to v2.0.0, it waits for the tab to be closed and reopened before being installed.
Back in the main thread, I'm manually updating the ServiceWorker after registration – otherwise the page never even gets the memo that there's a new version of the ServiceWorker available (oddly I found very few mentions of this anywhere in the ServiceWorker literature):
navigator.serviceWorker.register('/sw-bundle.js', {
scope: './'
}).then(registration => {
if (typeof registration.update == 'function') {
registration.update();
}
});
However, the content that gets served to the main thread is always stuck on an old version of the page ("My version is 1.0.0"), regardless of whether I increment the version to 1.0.1 or 2.0.0.
I'm kind of stumped here. I was hoping to find an elegant semver-y solution to ServiceWorker versioning (hence my use of require('./package.json').version), but in my current implementation, the user is perpetually stuck on an old version of the page, unless they hard-refresh or manually clear out all their data. :/
Found the issue – you need to avoid any cache headers on the ServiceWorker JS file itself. Setting the cache to max-age=0 immediately solved the problem: https://github.com/nolanlawson/serviceworker-update-demo/pull/1
Cheers to Jake Archibald for setting me straight: https://twitter.com/jaffathecake/status/689214019308224513
External: stop and unregister a service worker using chrome://serviceworker-internals/
Internal from service worker itself: https://developer.mozilla.org/en-US/docs/Web/API/Clients/claim and https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/skipWaiting
In Chrome Canary you can do all sort of Service Worker profiling and management like unregister, clear in the Applications Tab:
Pair that with chrome://devices/ to debug with your physical device.