Auto Update with electron-updater (WIP) #808
|
|
@ -462,9 +462,9 @@ app.on('before-quit', event => {
|
|||
event.preventDefault();
|
||||
showingAutoUpdateCloseAlert = true;
|
||||
dialog.showMessageBox({
|
||||
type: "info",
|
||||
title: "LBRY will upgrade",
|
||||
message: "Please select \"Yes\" at the upgrade prompt shown after the app closes.",
|
||||
type: 'info',
|
||||
title: 'LBRY Will Upgrade',
|
||||
message: 'LBRY has a pending upgrade. Please select "Yes" to install it on the prompt shown after this one.',
|
||||
}, () => {
|
||||
// After the user approves the dialog, we can quit once and for all.
|
||||
quitNow();
|
||||
|
|
|
|||
|
|
@ -13,9 +13,9 @@ class ModalAutoUpdateDownloaded extends React.PureComponent {
|
|||
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.
|
||||
<Modal
|
||||
isOpen={true}
|
||||
type="confirm"
|
||||
contentLabel={__("Update downloaded")}
|
||||
|
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.
|
||||
confirmButtonLabel={__("Update and Restart")}
|
||||
|
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.
|
||||
abortButtonLabel={__("Don't Update")}
|
||||
|
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.
|
||||
contentLabel={__("Update Downloaded")}
|
||||
|
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.
|
||||
confirmButtonLabel={__("Use it 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.
|
||||
abortButtonLabel={__("Upgrade on Restart")}
|
||||
|
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={() => {
|
||||
ipcRenderer.send("autoUpdateAccepted");
|
||||
}}
|
||||
|
|
@ -28,7 +28,7 @@ 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.
|
||||
<h3 className="text-center">{__("LBRY Leveled Up")}</h3>
|
||||
<p>
|
||||
|
I noticed a I noticed a `<br/>` was dropped here.
There are other modals (most?) with no There are other modals (most?) with no `<br />`, and it's not semantic, and seemed to look fine this way. What did you think of the look?
|
||||
{__(
|
||||
"A new version of LBRY has been downloaded and is ready to install."
|
||||
|
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.
|
||||
'A new version of LBRY has been released, downloaded, and is ready for you to use pending a restart.'
|
||||
|
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.
|
||||
)}
|
||||
</p>
|
||||
</section>
|
||||
|
|
|
|||
|
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.
|
||||
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"