Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor all sync and callback code uses to promises #30

Closed
nmushegian opened this issue Jul 10, 2015 · 4 comments
Closed

refactor all sync and callback code uses to promises #30

nmushegian opened this issue Jul 10, 2015 · 4 comments

Comments

@nmushegian
Copy link

I think everything in lib/ should use promises. Objections?

@iurimatias
Copy link
Collaborator

definitely! :)

@linagee
Copy link
Contributor

linagee commented Jul 24, 2015

I had this open in #39, but will just put it here instead because it is related:

It doesn't work for me. I'm running Ubuntu 14.10, embark 0.7.0, geth 0.9.39
This seems like a really bad way to implement it (but then, I was told it was a hack, so, eh..)

lib/deploy.js

      while ((receipt = web3.eth.getTransactionReceipt(transactionHash)) === null) {
          sleep.sleep(1);
      }

Sometimes I get "CONNECTION ERROR" (and sometimes it just quietly returned back to my shell without doing anything), I think web3 just trying over and over again to do JSON-RPC to geth. I tried to convert this into a way to use the callbacks on the .new() call to a contract that tell you the address, but then everything else broke. (Such as when it goes to write the ABI, it wasn't waiting for the transaction to finish being deployed, it was depending on this loop to repeat.)

I'm not sure what the best way to fix all of this is, unfortunately I'm not a JS expert. :-(

My mess of an attempt to try to make a callback for embark-framework: linagee@277a345#diff-eff50028862616c28af389bc1a879f9bR36

It actually did work, it's just I only moved the waiting one step down the line. It wrote the abi JS file without any contract contents because it didn't wait for it or something...?

Good luck converting it to promises/async stuff.

(Maybe "mac people" are having more luck than "Ubuntu people"? grumble grumble "mac people"... strokes beard)

edit:
Looking at the changes, I guess things are way different on the develop branch than 0.7.0...
This seems a lot simpler and maybe it would work better for me?

contractAddress = contractObject["new"].apply(contractObject, contractParams).address;

@danfinlay
Copy link

It seems like right now, in order to expose a totally synchronous API to the contract users in JS, there's a lot of sync JS under the hood too.

I would take the premise of this issue to the next level, and say all external contract APIs should be async, likely returning Promises, and all internal calls to provider.send() should be replaced with provider.sendAsync(), to create a more responsive UI in general.

@iurimatias
Copy link
Collaborator

this issue refered to embark 1, embark 2 changed greatly and does everything with async calls and promises.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants