Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
const Migrator = require('pojo-migrator')
|
2016-05-20 02:13:33 +02:00
|
|
|
const MetamaskConfig = require('../config.js')
|
2016-05-20 01:53:16 +02:00
|
|
|
const migrations = require('./migrations')
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
|
2016-05-20 01:53:16 +02:00
|
|
|
const TESTNET_RPC = MetamaskConfig.network.testnet
|
|
|
|
const MAINNET_RPC = MetamaskConfig.network.mainnet
|
2016-04-12 23:41:58 +02:00
|
|
|
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
/* The config-manager is a convenience object
|
|
|
|
* wrapping a pojo-migrator.
|
|
|
|
*
|
|
|
|
* It exists mostly to allow the creation of
|
|
|
|
* convenience methods to access and persist
|
|
|
|
* particular portions of the state.
|
|
|
|
*/
|
|
|
|
module.exports = ConfigManager
|
2016-06-25 00:52:56 +02:00
|
|
|
function ConfigManager (opts) {
|
2016-04-15 22:04:17 +02:00
|
|
|
// ConfigManager is observable and will emit updates
|
|
|
|
this._subs = []
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
|
|
|
|
/* The migrator exported on the config-manager
|
|
|
|
* has two methods the user should be concerned with:
|
|
|
|
*
|
|
|
|
* getData(), which returns the app-consumable data object
|
|
|
|
* saveData(), which persists the app-consumable data object.
|
|
|
|
*/
|
2016-06-21 22:18:32 +02:00
|
|
|
this.migrator = new Migrator({
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
|
|
|
|
// Migrations must start at version 1 or later.
|
|
|
|
// They are objects with a `version` number
|
|
|
|
// and a `migrate` function.
|
|
|
|
//
|
|
|
|
// The `migrate` function receives the previous
|
|
|
|
// config data format, and returns the new one.
|
2016-04-12 23:41:58 +02:00
|
|
|
migrations: migrations,
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
|
|
|
|
// How to load initial config.
|
|
|
|
// Includes step on migrating pre-pojo-migrator data.
|
2016-06-25 00:52:56 +02:00
|
|
|
loadData: opts.loadData,
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
|
|
|
|
// How to persist migrated config.
|
2016-06-25 00:52:56 +02:00
|
|
|
setData: opts.setData,
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setConfig = function (config) {
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
var data = this.migrator.getData()
|
|
|
|
data.config = config
|
|
|
|
this.setData(data)
|
2016-04-15 22:04:17 +02:00
|
|
|
this._emitUpdates(config)
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getConfig = function () {
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
var data = this.migrator.getData()
|
|
|
|
if ('config' in data) {
|
|
|
|
return data.config
|
|
|
|
} else {
|
|
|
|
return {
|
|
|
|
provider: {
|
2016-05-11 00:37:13 +02:00
|
|
|
type: 'testnet',
|
2016-06-21 22:18:32 +02:00
|
|
|
},
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setRpcTarget = function (rpcUrl) {
|
2016-04-01 01:32:35 +02:00
|
|
|
var config = this.getConfig()
|
|
|
|
config.provider = {
|
|
|
|
type: 'rpc',
|
|
|
|
rpcTarget: rpcUrl,
|
|
|
|
}
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setProviderType = function (type) {
|
2016-05-11 00:37:13 +02:00
|
|
|
var config = this.getConfig()
|
|
|
|
config.provider = {
|
|
|
|
type: type,
|
|
|
|
}
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.useEtherscanProvider = function () {
|
2016-04-01 01:32:35 +02:00
|
|
|
var config = this.getConfig()
|
|
|
|
config.provider = {
|
|
|
|
type: 'etherscan',
|
|
|
|
}
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getProvider = function () {
|
2016-04-01 01:32:35 +02:00
|
|
|
var config = this.getConfig()
|
|
|
|
return config.provider
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setData = function (data) {
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
this.migrator.saveData(data)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getData = function () {
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
return this.migrator.getData()
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setWallet = function (wallet) {
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
var data = this.migrator.getData()
|
|
|
|
data.wallet = wallet
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getSelectedAccount = function () {
|
2016-04-25 23:14:34 +02:00
|
|
|
var config = this.getConfig()
|
|
|
|
return config.selectedAccount
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setSelectedAccount = function (address) {
|
2016-04-25 23:14:34 +02:00
|
|
|
var config = this.getConfig()
|
|
|
|
config.selectedAccount = address
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getWallet = function () {
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
return this.migrator.getData().wallet
|
|
|
|
}
|
|
|
|
|
2016-03-31 19:47:40 +02:00
|
|
|
// Takes a boolean
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setShowSeedWords = function (should) {
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
var data = this.migrator.getData()
|
2016-03-31 19:47:40 +02:00
|
|
|
data.showSeedWords = should
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getShouldShowSeedWords = function () {
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
var data = this.migrator.getData()
|
2016-03-31 19:47:40 +02:00
|
|
|
return data.showSeedWords
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getCurrentRpcAddress = function () {
|
2016-05-11 00:37:13 +02:00
|
|
|
var provider = this.getProvider()
|
|
|
|
if (!provider) return null
|
2016-06-21 22:18:32 +02:00
|
|
|
switch (provider.type) {
|
2016-05-11 00:37:13 +02:00
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
case 'mainnet':
|
|
|
|
return MAINNET_RPC
|
2016-05-11 00:37:13 +02:00
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
case 'testnet':
|
|
|
|
return TESTNET_RPC
|
2016-05-11 00:37:13 +02:00
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
default:
|
|
|
|
return provider && provider.rpcTarget ? provider.rpcTarget : TESTNET_RPC
|
|
|
|
}
|
Made configuration migrateable
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.
2016-03-31 04:15:49 +02:00
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setData = function (data) {
|
2016-04-15 22:04:17 +02:00
|
|
|
this.migrator.saveData(data)
|
|
|
|
}
|
|
|
|
|
2016-04-28 23:16:24 +02:00
|
|
|
//
|
|
|
|
// Tx
|
|
|
|
//
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getTxList = function () {
|
2016-04-19 01:39:35 +02:00
|
|
|
var data = this.migrator.getData()
|
2016-04-28 23:16:24 +02:00
|
|
|
if (data.transactions !== undefined) {
|
2016-04-19 01:39:35 +02:00
|
|
|
return data.transactions
|
|
|
|
} else {
|
|
|
|
return []
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.unconfirmedTxs = function () {
|
2016-04-28 23:16:24 +02:00
|
|
|
var transactions = this.getTxList()
|
|
|
|
return transactions.filter(tx => tx.status === 'unconfirmed')
|
|
|
|
.reduce((result, tx) => { result[tx.id] = tx; return result }, {})
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype._saveTxList = function (txList) {
|
2016-04-19 01:39:35 +02:00
|
|
|
var data = this.migrator.getData()
|
|
|
|
data.transactions = txList
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.addTx = function (tx) {
|
2016-04-19 01:39:35 +02:00
|
|
|
var transactions = this.getTxList()
|
|
|
|
transactions.push(tx)
|
|
|
|
this._saveTxList(transactions)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getTx = function (txId) {
|
2016-04-19 01:39:35 +02:00
|
|
|
var transactions = this.getTxList()
|
|
|
|
var matching = transactions.filter(tx => tx.id === txId)
|
|
|
|
return matching.length > 0 ? matching[0] : null
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.confirmTx = function (txId) {
|
2016-04-19 01:39:35 +02:00
|
|
|
this._setTxStatus(txId, 'confirmed')
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.rejectTx = function (txId) {
|
2016-04-19 01:39:35 +02:00
|
|
|
this._setTxStatus(txId, 'rejected')
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype._setTxStatus = function (txId, status) {
|
2016-04-20 02:32:09 +02:00
|
|
|
var tx = this.getTx(txId)
|
|
|
|
tx.status = status
|
|
|
|
this.updateTx(tx)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.updateTx = function (tx) {
|
2016-04-19 01:39:35 +02:00
|
|
|
var transactions = this.getTxList()
|
2016-04-20 02:32:09 +02:00
|
|
|
var found, index
|
|
|
|
transactions.forEach((otherTx, i) => {
|
|
|
|
if (otherTx.id === tx.id) {
|
|
|
|
found = true
|
|
|
|
index = i
|
2016-04-19 01:39:35 +02:00
|
|
|
}
|
|
|
|
})
|
2016-04-20 02:32:09 +02:00
|
|
|
if (found) {
|
|
|
|
transactions[index] = tx
|
|
|
|
}
|
2016-04-19 01:39:35 +02:00
|
|
|
this._saveTxList(transactions)
|
|
|
|
}
|
2016-04-20 02:32:09 +02:00
|
|
|
|
2016-05-21 01:18:54 +02:00
|
|
|
// wallet nickname methods
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getWalletNicknames = function () {
|
2016-05-21 01:18:54 +02:00
|
|
|
var data = this.getData()
|
2016-06-21 22:18:32 +02:00
|
|
|
const nicknames = ('walletNicknames' in data) ? data.walletNicknames : {}
|
2016-05-21 01:18:54 +02:00
|
|
|
return nicknames
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.nicknameForWallet = function (account) {
|
|
|
|
const nicknames = this.getWalletNicknames()
|
2016-05-21 01:18:54 +02:00
|
|
|
return nicknames[account]
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setNicknameForWallet = function (account, nickname) {
|
|
|
|
const nicknames = this.getWalletNicknames()
|
2016-05-21 01:18:54 +02:00
|
|
|
nicknames[account] = nickname
|
|
|
|
var data = this.getData()
|
|
|
|
data.walletNicknames = nicknames
|
|
|
|
this.setData(data)
|
|
|
|
}
|
2016-04-28 23:16:24 +02:00
|
|
|
|
2016-04-15 22:04:17 +02:00
|
|
|
// observable
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.subscribe = function (fn) {
|
2016-04-15 22:04:17 +02:00
|
|
|
this._subs.push(fn)
|
|
|
|
var unsubscribe = this.unsubscribe.bind(this, fn)
|
|
|
|
return unsubscribe
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.unsubscribe = function (fn) {
|
2016-04-15 22:04:17 +02:00
|
|
|
var index = this._subs.indexOf(fn)
|
|
|
|
if (index !== -1) this._subs.splice(index, 1)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype._emitUpdates = function (state) {
|
|
|
|
this._subs.forEach(function (handler) {
|
2016-04-15 22:04:17 +02:00
|
|
|
handler(state)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.setConfirmed = function (confirmed) {
|
2016-06-17 00:04:50 +02:00
|
|
|
var data = this.getData()
|
|
|
|
data.isConfirmed = confirmed
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
2016-06-21 22:18:32 +02:00
|
|
|
ConfigManager.prototype.getConfirmed = function () {
|
2016-06-17 00:04:50 +02:00
|
|
|
var data = this.getData()
|
|
|
|
return ('isConfirmed' in data) && data.isConfirmed
|
|
|
|
}
|
|
|
|
|
2016-07-21 22:41:10 +02:00
|
|
|
ConfigManager.prototype.setShouldntShowWarning = function (confirmed) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.isEthConfirmed = confirmed
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getShouldntShowWarning = function () {
|
|
|
|
var data = this.getData()
|
|
|
|
return ('isEthConfirmed' in data) && data.isEthConfirmed
|
|
|
|
}
|