|
|
|
// polyfill fetch
|
|
|
|
global.fetch = global.fetch || require('isomorphic-fetch')
|
|
|
|
|
|
|
|
const assert = require('assert')
|
|
|
|
const configManagerGen = require('../lib/mock-config-manager')
|
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
|
|
|
|
|
|
|
describe('config-manager', function () {
|
|
|
|
var configManager
|
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
|
|
|
|
|
|
|
beforeEach(function () {
|
|
|
|
configManager = configManagerGen()
|
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
|
|
|
})
|
|
|
|
|
|
|
|
describe('#setConfig', 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.
9 years ago
|
|
|
it('should set the config key', function () {
|
|
|
|
var testConfig = {
|
|
|
|
provider: {
|
|
|
|
type: 'rpc',
|
|
|
|
rpcTarget: 'foobar',
|
|
|
|
},
|
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.setConfig(testConfig)
|
|
|
|
var result = configManager.getData()
|
|
|
|
|
|
|
|
assert.equal(result.config.provider.type, testConfig.provider.type)
|
|
|
|
assert.equal(result.config.provider.rpcTarget, testConfig.provider.rpcTarget)
|
|
|
|
})
|
|
|
|
|
|
|
|
it('setting wallet should not overwrite config', 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.
9 years ago
|
|
|
var testConfig = {
|
|
|
|
provider: {
|
|
|
|
type: 'rpc',
|
|
|
|
rpcTarget: 'foobar',
|
|
|
|
},
|
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.setConfig(testConfig)
|
|
|
|
|
|
|
|
var testWallet = {
|
|
|
|
name: 'this is my fake 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
|
|
|
}
|
|
|
|
configManager.setWallet(testWallet)
|
|
|
|
|
|
|
|
var result = configManager.getData()
|
|
|
|
assert.equal(result.wallet.name, testWallet.name, 'wallet name is set')
|
|
|
|
assert.equal(result.config.provider.rpcTarget, testConfig.provider.rpcTarget)
|
|
|
|
|
|
|
|
testConfig.provider.type = 'something else!'
|
|
|
|
configManager.setConfig(testConfig)
|
|
|
|
|
|
|
|
result = configManager.getData()
|
|
|
|
assert.equal(result.wallet.name, testWallet.name, 'wallet name is set')
|
|
|
|
assert.equal(result.config.provider.rpcTarget, testConfig.provider.rpcTarget)
|
|
|
|
assert.equal(result.config.provider.type, testConfig.provider.type)
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
describe('wallet nicknames', function () {
|
|
|
|
it('should return null when no nicknames are saved', function () {
|
|
|
|
var nick = configManager.nicknameForWallet('0x0')
|
|
|
|
assert.equal(nick, null, 'no nickname returned')
|
|
|
|
})
|
|
|
|
|
|
|
|
it('should persist nicknames', function () {
|
|
|
|
var account = '0x0'
|
|
|
|
var nick1 = 'foo'
|
|
|
|
var nick2 = 'bar'
|
|
|
|
configManager.setNicknameForWallet(account, nick1)
|
|
|
|
|
|
|
|
var result1 = configManager.nicknameForWallet(account)
|
|
|
|
assert.equal(result1, nick1)
|
|
|
|
|
|
|
|
configManager.setNicknameForWallet(account, nick2)
|
|
|
|
var result2 = configManager.nicknameForWallet(account)
|
|
|
|
assert.equal(result2, nick2)
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
describe('rpc manipulations', function () {
|
|
|
|
it('changing rpc should return a different rpc', 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.
9 years ago
|
|
|
var firstRpc = 'first'
|
|
|
|
var secondRpc = 'second'
|
|
|
|
|
|
|
|
configManager.setRpcTarget(firstRpc)
|
|
|
|
var firstResult = configManager.getCurrentRpcAddress()
|
|
|
|
assert.equal(firstResult, firstRpc)
|
|
|
|
|
|
|
|
configManager.setRpcTarget(secondRpc)
|
|
|
|
var secondResult = configManager.getCurrentRpcAddress()
|
|
|
|
assert.equal(secondResult, secondRpc)
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
describe('transactions', function () {
|
|
|
|
beforeEach(function () {
|
|
|
|
configManager.setTxList([])
|
|
|
|
})
|
|
|
|
|
|
|
|
describe('#getTxList', function () {
|
|
|
|
it('when new should return empty array', function () {
|
|
|
|
var result = configManager.getTxList()
|
|
|
|
assert.ok(Array.isArray(result))
|
|
|
|
assert.equal(result.length, 0)
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
describe('#setTxList', function () {
|
|
|
|
it('saves the submitted data to the tx list', function () {
|
|
|
|
var target = [{ foo: 'bar' }]
|
|
|
|
configManager.setTxList(target)
|
|
|
|
var result = configManager.getTxList()
|
|
|
|
assert.equal(result[0].foo, 'bar')
|
|
|
|
})
|
|
|
|
})
|
|
|
|
})
|
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
|
|
|
})
|