Conversation
@observer | ||
export default class ChangeVault extends Component { | ||
static propTypes = { | ||
store: PropTypes.object.isRequired, |
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.
It's a bit hard to know which store we're talking about here. Could use the same naming as vaultStore
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.
Makes sense, should have renamed with the others.
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.
On looking at the code. Store is the CreateAccount/store - used like that in all components in CreateAccount. (Not renaming it here accross all)
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.
Well, it's obvious what store it is inside the CreateAccount
context. It's less obvious in the ChangeVault
context (you cannot just look at the imports)
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.
~/ui/CreateAccount/ChangeVault
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.
But it could be used elsewhere : views/Account/Header
is not only used for Accounts
but also for Address
for example. Don't want to make a big thing, but I think that renaming it doesn't cost much and adds some readability.
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.
No issues either way, but not going to do it just for the component and the others are out of scope for the PR. We should probably do it everywhere, we pass it everywhere as store. (Not just this component). Issues -
- As you said, it may not be obvious from reading what we are dealing with (fails a bit in "write code for reading")
- It conflicts with Redux store naming, i.e. when a MobX store & Redux is used (couple of places), the MobX store cannot be called 'store' in props
Should be logged for a global refactor/cleanup - https://github.com/ethcore/parity/issues/4748
isOpen: false | ||
}; | ||
|
||
vaultStore = this.props.vaultStore || VaultStore.get(this.context.api); |
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.
Wouldn't it be better to choose whether it should be passed as prop or not? I find it a bit confusing
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.
Actually only done this way for testing.
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.
So.... ? One way or the other is fine, but we should choose one for consistency
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.
It only gets use by the tests here.
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.
So as a prop ? Thus we don't need the VaultStore.get(this.context.api)
?
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.
The tests (e.g. vaultSelect.spec.js) passes thrhough as prop to tightly control the conditions. Normal operations is via getter.
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.
Is there any other components that has this kind of logic ? I think that if we really want to have clean logic, we would have one pure component that gets everything via its props and that get tested, and one wrapper component that passes to this pure component the right props from whatever (a store instance, context, ...)
@@ -220,7 +226,28 @@ export default class Store { | |||
this.stage--; | |||
} | |||
|
|||
createAccount = () => { | |||
createAccount = (vaultStore) => { |
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.
Wouldn't it make sense to attach the vaultStore
to this Store before, instead of passing this as an argument (might be used for other methods)?
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.
No. We specifically don't want it in FirstRun. So it is an option, not a requirement.
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.
Could be optional without being an argument, no?
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.
I prefer passing it here when we create, only used at this point and set by the caller as an option.
Last one is another botched merge. :( |
Also, could we also use the tagged version of the Vault for the Account Summary in an Account page. It's not that great right now |
Not doing that in here. I will as soon as we have a proper tag mechanism in-place, as it stands it is just more duplication which I'm not up for. |
Looks good, still some code-style gumbles, not blocking though. |
Extending the work from #4446 & #4631, finally Closes https://github.com/ethcore/parity/issues/3501
Adds the following functionality -
Future work -
CreateAccount vault selection -
Vault information on account summary -
Depends on the following to be merged -
SelectionList component https://github.com/ethcore/parity/pull/4639ModalBox component https://github.com/ethcore/parity/pull/4637Hover info cards https://github.com/ethcore/parity/pull/4621Previous round of Vault UI changes https://github.com/ethcore/parity/pull/4631