Add the ability to pass an error in the callback of an event action.
Currently, event actions could either pass back a an error OR a result, but not both, and with no way to distinguish between the two parameters. This PR adds the ability to pass an error as the first parameter of the action callback.
An example of a use case that this fixed: errors on `deployIf` were silently swallowed, which has now been fixed.
All instances of `events.request(“deploy:contracts”)` were given an `error` parameter in their callback, and errors printed if it is not undefined.
All instances of `registerActionForEvent` were combed to ensure any callbacks were passing the expected error and result.
`web3.eth.getAccounts` was returning an empty array in the console due to a change, that I’m unsure of what the original intention was for.
@andremederios, could you please take a look, and let me know if this breaks the intention of the original changes?
Cockpit whisper messages were not being subscribed to due to a inocuous bug that would swallow errors and ultimately not be subscribed to the `rxjs` observer.
This PR fixes a number of issues relating to the cockpit console.
#### Console commands display in cockpit console
Fix cockpit console not displaying console usage commands that included “<usage option>”. For example “resolve <name>” would not display the “<name>” part, as it was attempting to write this in as HTML (ansi-to-html conversion).
This was fixed by replacing any instances of “<usage>” with “[usage]”. Please note that future usage strings should not contain text wrapped in “<>”.
#### Autosuggestions for “web.eth.” not appearing
Fix “web3.eth.” not suggesting members of `web3.eth`. This was due to a `Object.keys(web3.eth)` throwing `'getOwnPropertyDescriptor' on proxy: trap returned descriptor for property 'defaultAccount' that is incompatible with the existing property in the proxy target` in the console. Changing `Object.keys` to `Object.getOwnPropertyDescriptor` solved the problem.
#### Fix autosuggestion of known console commands (ie from plugins)
Fix known console commands (ie from plugins) not being autosuggested. For example, typing “web”, should autosuggest `webserver start/stop`, `log webserver on`, and `log webserver off`.
This PR adds in support for registered console commands (from plugins).
In addition to `EmbarkJS.Storage` not being available in the console (ie `await EmbarkJS.Storage.isAvailable() alway returned false), the error `Could not connect to a storage provider using any of the dappConnections in the storage config` would always appear in the console. The storage operations in the dapps were working OK.
The fix to this was three-fold:
1) Wait for the ipfs process to be started before attempting to run the `EmbarkJS.Storage.registerProvider/setProvider` in the console.
2) Wait for `EmbarkJS.Storage.registerProvider` to be called before `EmbarkJS.Storage.setProvider`. This was actually handled in the previous PR.
3) Remove any async operations from the `setProviders` method in the storage module. This was causing `callback is not defined` errors which were being swallowed and masqueraded as an unsuccessful attempt to connect to a `dappConnection` or `upload` config.
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
Fix demo not running, by fixing the following issues:
This was due to the removal of `Web3` from the VM initialisation in a recent PR. The reasoning behind the removal was so that the modules that need Web3 could require it as needed, however, it is needed in 3 modules (ENS, Whisper, and web3Connector), all of which would define `const Web = …` in the code generated EmbarkJS, thus causing issues in itself. This needs to be rethought prior to removing it from the VM sandbox.
Because Web3 is back to being required in the global sandbox of the VM, it does not need to be registered in the `web3Connector` module, hence the removal of the `runcode:register`.
Module not found: Error: Can't resolve 'embarkArtifacts/contracts/SimpleStorage.js' in '/Users/emizzle/temp/embark_demo/app/components’`
This was fixed by replacing
```
import SimpleStorage from 'Embark/contracts/SimpleStorage';
```
with
```
import SimpleStorage from '../../embarkArtifacts/contracts/SimpleStorage';
```
revert changes changing __Web3 to Web3
