Auto Update with electron-updater (WIP) #808
|
|
@ -436,9 +436,6 @@ app.on('before-quit', event => {
|
|||
shutdownDaemonAndQuit();
|
||||
} else {
|
||||
console.log('Quitting.');
|
||||
if (autoUpdating) {
|
||||
minimize = false;
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,6 @@ export const DOWNLOAD_UPGRADE = 'DOWNLOAD_UPGRADE';
|
|||
export const UPGRADE_DOWNLOAD_STARTED = 'UPGRADE_DOWNLOAD_STARTED';
|
||||
export const UPGRADE_DOWNLOAD_COMPLETED = 'UPGRADE_DOWNLOAD_COMPLETED';
|
||||
export const UPGRADE_DOWNLOAD_PROGRESSED = 'UPGRADE_DOWNLOAD_PROGRESSED';
|
||||
export const AUTO_UPDATE_DOWNLOAD_COMPLETED = "AUTO_UPDATE_DOWNLOAD_COMPLETED";
|
||||
export const CHECK_UPGRADE_AVAILABLE = 'CHECK_UPGRADE_AVAILABLE';
|
||||
export const CHECK_UPGRADE_START = 'CHECK_UPGRADE_START';
|
||||
export const CHECK_UPGRADE_SUCCESS = 'CHECK_UPGRADE_SUCCESS';
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ import app from './app';
|
|||
const { autoUpdater } = remote.require('electron-updater');
|
||||
const { contextMenu } = remote.require('./main.js');
|
||||
|
||||
autoUpdater.logger = remote.require("electron-log");
|
||||
|
||||
window.addEventListener('contextmenu', event => {
|
||||
contextMenu(remote.getCurrentWindow(), event.x, event.y, app.env === 'development');
|
||||
event.preventDefault();
|
||||
|
|
@ -102,6 +104,18 @@ const init = () => {
|
|||
app.store.dispatch(doAutoUpdate());
|
||||
});
|
||||
|
||||
if (["win32", "darwin"].includes(process.platform)) {
|
||||
autoUpdater.on("update-available", () => {
|
||||
console.log("Update available");
|
||||
});
|
||||
autoUpdater.on("update-not-available", () => {
|
||||
console.log("Update not available");
|
||||
});
|
||||
autoUpdater.on("update-downloaded", () => {
|
||||
console.log("Update downloaded");
|
||||
app.store.dispatch(doAutoUpdate());
|
||||
});
|
||||
}
|
||||
app.store.dispatch(doDownloadLanguages());
|
||||
|
||||
function onDaemonReady() {
|
||||
|
|
|
|||
|
|
@ -3,8 +3,7 @@ import { Modal } from "modal/modal";
|
|||
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
import { Line } from "rc-progress";
|
||||
import Link from "component/link/index";
|
||||
|
||||
const { remote } = require("electron");
|
||||
|
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
const { autoUpdater } = remote.require("electron-updater");
|
||||
|
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
const { ipcRenderer } = require("electron");
|
||||
|
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
|
||||
class ModalAutoUpdateDownloaded extends React.PureComponent {
|
||||
render() {
|
||||
|
|
@ -13,7 +12,9 @@ class ModalAutoUpdateDownloaded extends React.PureComponent {
|
|||
|
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
isOpen={true}
|
||||
contentLabel={__("Update downloaded")}
|
||||
confirmButtonLabel={__("Update and Restart")}
|
||||
onConfirmed={autoUpdater.quitAndInstall()}
|
||||
|
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
onConfirmed={() => {
|
||||
|
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
ipcRenderer.send("autoUpdate");
|
||||
|
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
}}
|
||||
|
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
>
|
||||
<section>
|
||||
<h3 className="text-center">{__("LBRY Leveled Up")}</h3>
|
||||
|
|
|
|||
|
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
This isn't necessarily a blocker, but is there a strong reason we have to expose This isn't necessarily a blocker, but is there a strong reason we have to expose `ipcRenderer` inside of a component, as well as put all of the handling of these events inside of `main/index.js`? Could this component instead dispatch an `APP_QUIT` action, and a reducer could close the app? (Or the top-level component?)
"Use It Now" "Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart. A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart" "Not Now" or "Upgrade on Restart"
I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed). Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window? I was going back and forth on this. Technically, neither of these IPC calls have anything to do with the store, and they do not lead to DOM updates. The "autoUpdateAccepted" IPC call tells the main process that it's time to shut down and restart (not UI state) and the "autoUpdateDeclined" IPC call just tells the main process to remember that the update was declined so that it can show the extra dialog on Windows (again, not UI state; the dialog is created by the main process and only appears after the app window is closed).
Is it typical to put code in Redux-land when it is only used for its side effects and doesn't affect anything going on in the browser window?
I think this is fine to leave as-is, at least for now. I think this is fine to leave as-is, at least for now.
|
||||
|
|
@ -111,7 +111,7 @@ export function doAutoUpdate() {
|
|||
const state = getState();
|
||||
dispatch({
|
||||
type: types.OPEN_MODAL,
|
||||
data: modals.AUTO_UPDATE_DOWNLOADED,
|
||||
data: { modal: modals.AUTO_UPDATE_DOWNLOADED },
|
||||
});
|
||||
};
|
||||
}
|
||||
|
|
|
|||
This isn't necessarily a blocker, but is there a strong reason we have to expose
ipcRendererinside of a component, as well as put all of the handling of these events inside ofmain/index.js? Could this component instead dispatch anAPP_QUITaction, and a reducer could close the app? (Or the top-level component?)"Use It Now"
A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.
"Not Now" or "Upgrade on Restart"