feat(migration): adjust BackendProcess, main.dev.js & App.ts so we can coordinate migrations!
#571
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…d launch We refactor the `BackendProcess` class to have specific methods that the main process can use to orchestrate launching the backend app Because we can only emit events to the renderer process in the main process (so no way to emit them in `BackendProcess`, unless we pass the `mainWindow` down to the `BackendProcess` class) this exposes a bunch of launching functionality to the main process (it was previously all hidden in the `backendProcess.maybeStartup()` function) In future refactors, am definitely open to pushing `mainWindow` down to `BackendProcess` and dealing with all aspects down there. However, as a first iteration I think this is fine. The logic for this the start up goes like this: - if a backend process is already running, error. Catch the error & send a message to the renderer that a qri backend is already running - check if we have a compatible backend version. If it's too low, send a message to the renderer that the version is incompatible - check if we need a migration - if we do, send a message to the renderer that we are migrating - launch the backend
- add `BootupComponentType` - `state.ui.bootupComponet` defaults to 'loading' - add `UI_SET_BOOTUP_COMPONENT` action type - add `setBootstrapComponent` action - add `selectBootstrapComponent` selector
Both the renderer process and main process need to be on before we can successfully coordinate behavior. `App` component now emits an `app-fully-loaded` event. Moved the backend launching process into the ipcMain `app-fully-loaded` event handler. This also means that whenever the app re-loads, we check for a backend connection, and if we don't find one we launch again. Which I think is a nice pick up! Downside is we get slightly longer loading time in dev mode (since it takes a bit to compile the app), but no discernible changes in prod mode!
now that the backend flags/expectations have changed, we can run any comand to see if it exits with code `2` (which indicates that a migration is needed)
b5
approved these changes
Jul 16, 2020
…onfig` as migration check
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #566
My journey through this process has been decently well chronicled in the above issue!
My last comment would be, very open to re-structuring
BackendProcessto take awindowso that the main function is less unwieldy and is less responsible for coordinating the behavior. However, it might be nice to keep all the emitted events in themain.development.jsfile, so that behavior isn't hidden down in another class. Anyone have strong opinions?Edit:
Backend is getting a refactor! Now commands won't "auto-trigger" a migration, unless you have the
--migrationsflag. And a command will fail w/ an exit error (2) if the config needs a migration. We can use these to remove the desktop's reliance on knowing about the QRI_PATH and keeping track of config revisions!