|
|
|
const ethUtil = require('ethereumjs-util')
|
|
|
|
const normalize = require('eth-sig-util').normalize
|
|
|
|
const {
|
|
|
|
MAINNET_RPC_URL,
|
|
|
|
ROPSTEN_RPC_URL,
|
|
|
|
KOVAN_RPC_URL,
|
|
|
|
RINKEBY_RPC_URL,
|
|
|
|
} = require('../controllers/network/enums')
|
|
|
|
|
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.
9 years ago
|
|
|
/* 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
|
|
|
|
function ConfigManager (opts) {
|
|
|
|
// ConfigManager is observable and will emit updates
|
|
|
|
this._subs = []
|
|
|
|
this.store = opts.store
|
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.
9 years ago
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setConfig = function (config) {
|
|
|
|
var data = this.getData()
|
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.
9 years ago
|
|
|
data.config = config
|
|
|
|
this.setData(data)
|
|
|
|
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.
9 years ago
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getConfig = function () {
|
|
|
|
var data = this.getData()
|
|
|
|
return data.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.
9 years ago
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setData = function (data) {
|
|
|
|
this.store.putState(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.
9 years ago
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getData = function () {
|
|
|
|
return this.store.getState()
|
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.
9 years ago
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setPasswordForgotten = function (passwordForgottenState) {
|
|
|
|
const data = this.getData()
|
|
|
|
data.forgottenPassword = passwordForgottenState
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getPasswordForgotten = function (passwordForgottenState) {
|
|
|
|
const data = this.getData()
|
|
|
|
return data.forgottenPassword
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setWallet = function (wallet) {
|
|
|
|
var data = this.getData()
|
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.
9 years ago
|
|
|
data.wallet = wallet
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setVault = function (encryptedString) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.vault = encryptedString
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getVault = function () {
|
|
|
|
var data = this.getData()
|
|
|
|
return data.vault
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getKeychains = function () {
|
|
|
|
return this.getData().keychains || []
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setKeychains = function (keychains) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.keychains = keychains
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getSelectedAccount = function () {
|
|
|
|
var config = this.getConfig()
|
|
|
|
return config.selectedAccount
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setSelectedAccount = function (address) {
|
|
|
|
var config = this.getConfig()
|
|
|
|
config.selectedAccount = ethUtil.addHexPrefix(address)
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getWallet = function () {
|
|
|
|
return this.getData().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.
9 years ago
|
|
|
}
|
|
|
|
|
|
|
|
// Takes a boolean
|
|
|
|
ConfigManager.prototype.setShowSeedWords = function (should) {
|
|
|
|
var data = this.getData()
|
|
|
|
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.
9 years ago
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
ConfigManager.prototype.getShouldShowSeedWords = function () {
|
|
|
|
var data = this.getData()
|
|
|
|
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.
9 years ago
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setSeedWords = function (words) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.seedWords = words
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getSeedWords = function () {
|
|
|
|
var data = this.getData()
|
|
|
|
return data.seedWords
|
|
|
|
}
|
|
|
|
ConfigManager.prototype.setRpcTarget = function (rpcUrl) {
|
|
|
|
var config = this.getConfig()
|
|
|
|
config.provider = {
|
|
|
|
type: 'rpc',
|
|
|
|
rpcTarget: rpcUrl,
|
|
|
|
}
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setProviderType = function (type) {
|
|
|
|
var config = this.getConfig()
|
|
|
|
config.provider = {
|
|
|
|
type: type,
|
|
|
|
}
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.useEtherscanProvider = function () {
|
|
|
|
var config = this.getConfig()
|
|
|
|
config.provider = {
|
|
|
|
type: 'etherscan',
|
|
|
|
}
|
|
|
|
this.setConfig(config)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getProvider = function () {
|
|
|
|
var config = this.getConfig()
|
|
|
|
return config.provider
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getCurrentRpcAddress = function () {
|
|
|
|
var provider = this.getProvider()
|
|
|
|
if (!provider) return null
|
|
|
|
switch (provider.type) {
|
|
|
|
|
|
|
|
case 'mainnet':
|
|
|
|
return MAINNET_RPC_URL
|
|
|
|
|
|
|
|
case 'ropsten':
|
|
|
|
return ROPSTEN_RPC_URL
|
|
|
|
|
|
|
|
case 'kovan':
|
|
|
|
return KOVAN_RPC_URL
|
|
|
|
|
|
|
|
case 'rinkeby':
|
|
|
|
return RINKEBY_RPC_URL
|
|
|
|
|
|
|
|
default:
|
|
|
|
return provider && provider.rpcTarget ? provider.rpcTarget : RINKEBY_RPC_URL
|
|
|
|
}
|
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.
9 years ago
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Tx
|
|
|
|
//
|
|
|
|
|
|
|
|
ConfigManager.prototype.getTxList = function () {
|
|
|
|
var data = this.getData()
|
|
|
|
if (data.transactions !== undefined) {
|
|
|
|
return data.transactions
|
|
|
|
} else {
|
|
|
|
return []
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setTxList = function (txList) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.transactions = txList
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// wallet nickname methods
|
|
|
|
|
|
|
|
ConfigManager.prototype.getWalletNicknames = function () {
|
|
|
|
var data = this.getData()
|
|
|
|
const nicknames = ('walletNicknames' in data) ? data.walletNicknames : {}
|
|
|
|
return nicknames
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.nicknameForWallet = function (account) {
|
|
|
|
const address = normalize(account)
|
|
|
|
const nicknames = this.getWalletNicknames()
|
|
|
|
return nicknames[address]
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setNicknameForWallet = function (account, nickname) {
|
|
|
|
const address = normalize(account)
|
|
|
|
const nicknames = this.getWalletNicknames()
|
|
|
|
nicknames[address] = nickname
|
|
|
|
var data = this.getData()
|
|
|
|
data.walletNicknames = nicknames
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
// observable
|
|
|
|
|
|
|
|
ConfigManager.prototype.getSalt = function () {
|
|
|
|
var data = this.getData()
|
|
|
|
return data.salt
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setSalt = function (salt) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.salt = salt
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.subscribe = function (fn) {
|
|
|
|
this._subs.push(fn)
|
|
|
|
var unsubscribe = this.unsubscribe.bind(this, fn)
|
|
|
|
return unsubscribe
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.unsubscribe = function (fn) {
|
|
|
|
var index = this._subs.indexOf(fn)
|
|
|
|
if (index !== -1) this._subs.splice(index, 1)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype._emitUpdates = function (state) {
|
|
|
|
this._subs.forEach(function (handler) {
|
|
|
|
handler(state)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.setLostAccounts = function (lostAccounts) {
|
|
|
|
var data = this.getData()
|
|
|
|
data.lostAccounts = lostAccounts
|
|
|
|
this.setData(data)
|
|
|
|
}
|
|
|
|
|
|
|
|
ConfigManager.prototype.getLostAccounts = function () {
|
|
|
|
var data = this.getData()
|
|
|
|
return data.lostAccounts || []
|
|
|
|
}
|