-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Conversation
.filter((s) => s.waiting) | ||
.map((s) => s.idx); | ||
} | ||
constructor (api, props) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would prefer being a bit more explicit here instead of just "props". Maybe the right approach would be to have
constructor (api, { accounts, onClose })
(Small difference, but always visible what is expected)
js/src/api/rpc/parity/parity.js
Outdated
.execute('parity_postTransaction', inOptions(options)); | ||
.execute('parity_postTransaction', parsedOptions) | ||
.then((requestId) => { | ||
this._transport.emit('request', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would make more sense on the logging layer where events are already fired. As it stands it now does the "same" thing in 2 different places.
@@ -203,7 +194,9 @@ export default class WalletSettingsStore { | |||
}); | |||
} | |||
|
|||
constructor (api, wallet) { | |||
constructor (api, props) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
constructor (api, { wallet, onClose })
(Just so it is obvious what to expect, as opposed to passing anything in)
|
||
const nextState = { | ||
...state, | ||
[ requestId ]: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[requestId]: {...}
would make more sense, not an array/spaced, rather a key.
|
||
import styles from './scrollableText.css'; | ||
|
||
export default function ScrollableText (props) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would prefer ({ small = false, text }) (especially in this case where the signature is on top and the properties only follow much later - linter still catches non-defined use in these cases)
js/src/util/tx.js
Outdated
|
||
const contractAddress = receipt.contractAddress; | ||
|
||
return api.eth.getCode(contractAddress) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
api.eth
.getCode(...)
.then(...)
(Just align with what we have elsewhere)
Ok, the overlay of dialogs needs to go, it really is super annoying when I actually try to get work done. (Which is what this improves, i.e. you can do multiples all at once.) Colours much better here, couldn't test the minimize (since I have the transactions overlaying my dialogs and have to keep moving them out of the way), but seems like a step in the right direction. The txhash still seems way too long where it is displayed. Possibly would make sense to make that (txhash) a click-through to etherscan and have it available somehow in the actual list as well. (Real scenario - just sent ETH and wanted to send the txhash to somebody, couldn't easily find it without going back into my account. Just having it shortened and clickable will allow that) Having said all that - love it :) |
So to test the animation, you can create a transaction without signing it, close the signer, create a new one, and then close the bottom pending transaction popup. I will update the z-indexes so that modals are always on top. @CraigglesO The transactions will auto-hide when they are validated (after being included into 6 blocks). This might be wrong for transactions with conditions though... But you can always hide those by clicking on them. The fact that they are persistent across page reloads is wanted, and it is especially useful when you deploy a contract! |
@ngotchac I'm not 100% sure transactions with conditions show up here. (I could be wrong, but I submitted one this morning and it didn't show - then again, was looking at 20 things in this PR at once, so could be wrong - briefly bugged me, I would just double-check the intent and if you are happy with the way it is handled.) |
@jacogr They are indeed displayed even with conditions. This is IMO the expected behavior so it's fine, but if it doesn't work on your side, there is an issue... |
As discussed, getting there, but a couple of things remaining -
and not worth a grumble...
|
I took care of every gumbles. |
Show transactions progress in the UI on the bottom-right corner, so the user can continue working while the transaction is in progress.
Still need to :
We might want to add this also for dapps. It would be basically a one line change, but not sure we want to add it though...