Refactor Containers and Routes in order to make the code a little more
readable, reduce duplication, and prepare the codebase for integration
of the new Home screen.
- Break out the Root container into several smaller containers that are
responsible for connecting themselves to the Redux store.
- Use routing for navigation between primary containers
- Unbundle the `Syncing` Component from the Onboarding section and hook
up to router so that it can be access by navigating to `/syncing' (we
want to be able to load existing wallets and initiate syncing outside of
the context of the onboarding process)
- Reduce code duplication
- Create `TitleBar` component and implement once at the top level
- Create `withLoading` HOC and use to display the loading screen when
needed.
If there is a problem connecting to the Lightning interface on a local
lnd instance, return the user to the onboarding screen and show the
user the error message.
Previously, the app would hang on an infinite loading screen.
Select free ports for lnd from a pool of options. By default we will
use the standard lnd ports (10009 and 9735) but if those are not
available then we will search for free ports in a nearby range.
This allows us to have multiple instances of the wallet running and
avoids possible conflicts with other instances of lnd that the user
may be running.
Consolidate the flow for local and remote wallet connections for
consolidate. When unlocking a local wallet wait for the macaroon to be
generated before we try to use it.
There is no need to check wether an lnd process exists and prevent
Zap from starting if so. We don't care if there is another process
running. We only care that we can successfully start up our own process.
If there is a conflict with another lnd process such as a port that we
need already being in use we already handle this elsewhere in our code.
If when connecting to a remote wallet we detect that it is locked
initialise the wallet unlocker to allow users to unlock their remote
wallets.
Fix#543
When connecting to a remote wallet we assume that the wallet is already
unlocked. In the case where it is not already unlocked, forward the
error message to the UI.
Fix#738
Fix an issue that was preventing grpc connection errors from showing
after a failed connection to a remote node.
Re-throw the error from `startLightningWallet` after logging it so that
it can be handled properly afterwards.
Lnd doesn't currently do a graceful shutdown when a `SIGTERM` is issued.
To ensure a graceful shutdown, call `stopDaemon` on the gRPC interface
prior to terminating lnd. If a graceful shutdown is unsuccessful then
force kill the daemon.
The `onOnboarding` state transition handler only fires if you are
entering the `onboarding` state from another state. If you are already
in the `onboarding` state it does not fire when the `startOnboarding`
event is initiated. By contrast, `onStartOnboarding` always fires when
`startOnboarding` is run.
Ensure that IPC listeners are only registered once when transitioning to
the `onboarding` state from another state.
If a full refresh is done from within the app (`cmd + r`) restart the
onboarding process from the beginning, including stopping lnd and
disconnecting any active connections.
Fix#641
On darwin, we keep the app running and just hide it when the window is
closed as that is the standard convention. On linux and windows the app
should be quit when the window is closed.
This resolves an issue where on linux/windows the app would remain open
when the window is closed, with no way to properly quit it short of
doing a force quit.
The standard approach on Darwin is to keen applications running when the
window is closed. Clicking the apps icon again in the doc should bring
back the application window.
This changeset refactors things to handle this. It will keep Zap and lnd
running in the background when the main application window is closed.
Quitting the app will stop both the app and lnd.
Fix#586Fix#601
Handle the case were the Neutrino backend BTCd node is still
synchronising the blockchain as LND is not able to start syncing
until the BTCd node that it is connected to is fully synced.
Fetch the current block height from multiple block explorers early on in
the sync process. This ensures that we get the correct block height in
the case where our BTCd node is still mid way through syncing. Do this
in the main process rather than in the render process.
Determine the current block height directly from the lnd log output and
pass the data into the app as soon as we have it. Do not call out to
block explorers if we don't need to.
Fix a race condition that could cause the app to think that it is still
syncing even after it has completed and as a result being stuck
reporting 100% syncing during the onboarding process.
`startGrpc` can take some time to fully establish and verify that th
connection is set up as we wait for a successful result from a call to
`getInfo`.
Previously, we would send the `lndSyncing` message to the app only after
`startGrpc` was complete. However, if the syncing process had actually
completed before `startGrpc` then we would first notify that syncing had
completed, only to then notify that it had started after it had already
completed.
In this fix, we notify the app of `lndSyncing` immediately after the
wallet has been unlocked.
Fix#525
`main.dev.js` was hard to follow and understand the code flow. It housed
code to handle quite a few distinct things. This is a fairly substantial
refactor of the application startup code in which we:
A new `Neutrino` class has been created with 2 public methods. `start`
and `stop`. `start` will launch a new `lnd` process whilst `stop` will
stop it. This class extends the `EventEmitter` class and emits the
following events based on activity detected from the lnd log output.
- `grpc-proxy-started` - gRPC started
- `wallet-opened` Wallet opened
- `fully-synced` - lnd is all caught up to the blockchain
- `got-block-height` - got updated block height
A new `ZapController` class has been created which houses all of the
logic for intraprocess communication between the main and renderer
processes.
Previously we had several `setInterval` loops that were checking every
second to see if the application status has changed and trigging the
appropriate action if so. This was pretty hard to follow has been
replaced here with more extensive use of promises. This enables us to
act instantly to relevant changes rather than waiting up to 1 second
for the next interval to fire.
Now, the only stuff that lives in `main.dev.js` now is the top level
`app` listeners, which calls out the other parts mentioned above to
bootstrap the application.
Tom Kirkpatrick
statoshi
Tom Kirkpatrick
Ben Woosley