parity-js / api Goto Github PK
View Code? Open in Web Editor NEWMoved to https://github.com/paritytech/js-libs/tree/master/packages/api
License: GNU General Public License v3.0
Moved to https://github.com/paritytech/js-libs/tree/master/packages/api
License: GNU General Public License v3.0
E.g.
contract C {
function myFunc(uint input) returns (uint) {
revert();
}
}
// setup api and get contract
const res = await C.instance.myFunc.call({}, [3]); // returns 0 rather than throwing error
Feel free to close this as invalid if you think the semantics of parity.js call
should be to return the default when the call fails, but it seems like throwing an error is more appropriate here.
This is issue is a follow up for the one in the old repo issue. The number of rpc calls of the polling method makes impossible to us to use api.subscribe.
Using this on a Nodejs environment, and using Websocket transport, it throws an error regarding window
is not defined. This only happens if it get disconnect and tries to reconnect, or when you get an error from the response.
This window
error comes from this lines.
Line 78 in a352de9
Line 121 in a352de9
Line 197 in a352de9
If I define a contract with an overloaded function, then try to call the function from the parity.js contract instance, I can only access one of the functions by name.
e.g.
contract C {
function myFunc(address a) { return; }
function myFunc(address a, uint b) { return; }
}
// after getting contract instances
theContract.instance.myFunc.call({}, ['0x0']); // errors due to missing property in array
theContract.instance.myFunc.call({}, ['0x0', 22]); // works fine
Workaround right now is to use the function signature bytes, (something like theContract.instance.be45fd62.call
) which are different for each of the functions.
The code that causes this behaviour is here, where the value of the property corresponding to the function name is overwritten.
One possible fix would be to make contract.instance.myFunc
dynamically determine which signature should be called based on the types of the arguments, and then call with the correct function signature based on that. The issue I see with this approach is that js is not typed the same way solidity is, so inferring the types may not be accurate.
Seems like web3 handles it like this (setting key as func(argType1,argType2)
), and this (choosing the function with the correct "shape" of parameters, if only one such function exists).
I believe the @parity/api
-interface (and especially the oo7 Bonds wrapper around it) are a marvellous way to write Decentralized Applications that is greatly preferable over manually short-polling the Ethereum Wallet for changes every couple of seconds.
However, @parity/api
currently is only built in such a way that it works well with a locally running lite or full wallet that is exposed over localhost:8545
. Especially users of MetaMask (which, although it of course has its limitations, is a gradual introduction into the Ethereum ecosystem), or users that browse the app directly in Mist, will inject their own Web3
, and their own Provider.
Now it seems to me that the web3.currentProvider
that is injected follows the same API as the Api.Provider
object that @parity/api
expects. However, this is based on duck-typing and also I have only verified this on a superficial level during the Blockchaingers Hackathon last week.
// sets up Bonds in a way that is compatible with MetaMask (and hopefully Mist as well)
import {bonds, options as bonds_options} from 'oo7-parity';
import Api from '@parity/api';
import BundledWeb3 from 'web3';
var provider;
var parityapi;
var web3;
window.addEventListener('load', function() {
// Checking if Web3 has been injected by the browser environment
if (typeof window.web3 !== 'undefined') {
// Use the browser's ethereum provider
window.provider = provider = window.web3.currentProvider
web3 = window.web3;
window.parityapi = parityapi = new Api(provider) // <- Fingers crossed!
bonds_options.api = parityapi
} else {
// Use bundled Web3 that assumes a wallet is running locally at port 8545
window.provider = provider = new BundledWeb3.providers.HttpProvider("http://localhost:8545");
window.web3 = web3 = new BundledWeb3(provider);
}
});
export {bonds, bonds_options, web3};
(The window.*
assignments are there for debugging purposes, and to make sure that the stuff that was already injected in this global context is also properly wrapped)
Would this (or probably: something based on this) be the proper way to ensure that @parity/api
works with other wallets as well? Or should a different approach be taken?
Input:
await api.personal.unlockAccount('0x35703012d6d353c33ef006c22dfd04a04dd6523a', 'password', 0);
Output:
personal_unlockAccount(["0x35703012d6d353c33ef006c22dfd04a04dd6523a","password",0]): -32602: Invalid params: invalid type: integer `0`, expected a 0x-prefixed, hex-encoded number of length 32.
(node:8567) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TransportError: personal_unlockAccount: -32602: Invalid params: invalid type: integer `0`, expected a 0x-prefixed, hex-encoded number of length 32.
(node:8567) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
May be due to calling inNumber10
here? I can see that throwing an error if the RPC endpoint expects something in hex.
Perhaps it should be inNumber16
instead.
(node:22916) UnhandledPromiseRejectionWarning: ReferenceError: window is not
defined
at Object.<anonymous> (/home/logan/.nvm/versions/node/v9.3.0/lib/node_modul
es/eac.js/node_modules/@parity/api/lib/provider/ipc.js:20:19)
at Module._compile (module.js:660:30)
at Object.Module._extensions..js (module.js:671:10)
at Module.load (module.js:573:32)
at tryModuleLoad (module.js:513:12)
at Function.Module._load (module.js:505:3)
at Module.require (module.js:604:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/home/logan/.nvm/versions/node/v9.3.0/lib/node_modul
es/eac.js/node_modules/@parity/api/lib/provider/index.js:18:11)
at Module._compile (module.js:660:30)
The code using Parity API package:
const hasPendingParity = async (conf, txRequest) => {
/// Only available if using parity locally.
const pApi = require("@parity/api")
const provider = new pApi.Provider.Http(`${conf.provider}`)
const api = new pApi(provider)
const transactions = await api.parity.pendingTransactions()
const recips = transactions.map(tx => tx.to)
if (recips.indexOf(txRequest.address) !== -1) return true
return false
}
As far as I can tell this has to do with the IPC provider which was added in the latest release. I'm going to downgrade since this was last working on version 2.1.16.
Could be useful to add a timed-out
error in the PostMessage
provider if no response has been received for more than N seconds.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.