aboutsummaryrefslogtreecommitdiffstats
path: root/test/unit/config-manager-test.js
Commit message (Collapse)AuthorAgeFilesLines
* Naming issue.Kevin Serrano2016-08-251-1/+1
|
* Implement usage of nock.Kevin Serrano2016-08-251-2/+11
|
* Now calls API functions with mock options.Kevin Serrano2016-08-251-3/+5
|
* Enforce tx history limitDan Finlay2016-08-191-0/+11
|
* Added compliance for tests and properly accounts for N/A conversions.Kevin Serrano2016-08-171-7/+6
|
* Remove extra test.Kevin Serrano2016-08-171-4/+0
|
* Change function names. Add interval polling for api. Refactor functions.Kevin Serrano2016-07-221-3/+3
|
* Progress on config manager. Plus tests.Kevin Serrano2016-07-211-1/+81
|
* Remove useless and buggy clearWallet functionDan Finlay2016-07-011-11/+0
|
* Replicated really strange bug with testDan Finlay2016-07-011-1/+16
|
* Fixed testsDan Finlay2016-06-251-2/+5
|
* Add confirmation persisting to localStorageDan Finlay2016-06-171-1/+31
|
* Added ability to nickname wallets locallyDan Finlay2016-05-211-0/+21
| | | | The changes are persisted to localstorage, so they cannot be restored on a new computer, but for right now it's a nice organizational feature.
* Store metamaskId on metaTx instead of getTxWithParams method.Dan Finlay2016-04-211-26/+0
|
* Add extra tx methods to configManagerDan Finlay2016-04-201-0/+36
|
* Persist transactions to config-managerDan Finlay2016-04-191-0/+79
| | | | | | | | 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.
* Made configuration migrateableDan Finlay2016-03-311-0/+71
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.