| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Transactions are now stored, and are never deleted, they only have their status updated.
We can add deleting later if we'd like.
I've hacked on emitting the new unconfirmedTx key to the UI in the format it received before, I want Aaron's opinion on where I should actually do that.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This boolean is computed from these requirements:
- The user is on the testnet rpc
- The account is index 0
The UI is responsible for checking the account balancing and indicating if fauceting is indeed pending or not.
|
| |
|
|
| |
If `setSelectedAddress` is called on the IdStore, the first account is automatically selected.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
|
| | |
|
| |
|
|
| |
When first creating a vault, the first account is submitted to our `rawtestrpc` faucet, receiving `1.337` ether within 15-30 seconds.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also added the hdPath that Christian had told me to our calls to the LightWallet, but this does not seem to have made us generate the same accounts as `testrpc` yet.
|
| |
|
|
|
|
| |
Added initial test just to verify we can recover the accounts we generate in this way.
Still need to add compliance test to make sure this interoperates with testrpc's new mnemonic flag.
|
| | |
|
| |
|
|
|
|
|
|
| |
In order to persist the seed word page until the user clicks the confirmation button, we need to store the seed words in localStorage.
To simplify this process I've also reorganized some of the account manager code, broken up one large function into many smaller functions, and created a new class for the IdMgmt object.
Again, sorry such a big refactor in one commit, but I really had to break it down to work through it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
