I needed a component that displays an identicon or shop Logo together with a label in a column layout.
Two options would have been to create a new component for that or to add a compact flag or something like that to the AccountInfo component which is closest implementation wise.
The second approach is the one used in the keyguard (where the more compact AddressInfo version can be expanded with more details via a isDetailedView flag).
However, as in vue-components there are already quite some Account*, Address*, Wallet*, Contact* components, I didn't want to further add to that confusion. Therefore I didn't want to add a new component. Also, I thought the missing separation of concerns between an inline component and a full page component that sort of arbitrarily changes its semantics by setting a flag (becoming a full screen view with added details and a close button) would not help to reduce the clutter.
Instead, I decided to consolidate functionality in the basic Account component which was then also used in AccountInfo and PaymentInfoLine to remove some code duplication.
Additionally, the account renaming screen in the new designs will be straight forward to implement with the already existing label editing functionality in the Account component.
Also some demos have been refactored / consolidated / made more interactive by adding knobs.
Lastly, the AccountInfo component was renamed to AccountDetails to avoid confusion with the AccountInfo interface we have in the account manager.
I needed a component that displays an identicon or shop Logo together with a label in a column layout. Two options would have been to create a new component for that or to add a
compact
flag or something like that to theAccountInfo
component which is closest implementation wise. The second approach is the one used in the keyguard (where the more compactAddressInfo
version can be expanded with more details via aisDetailedView
flag).However, as in vue-components there are already quite some
Account*
,Address*
,Wallet*
,Contact*
components, I didn't want to further add to that confusion. Therefore I didn't want to add a new component. Also, I thought the missing separation of concerns between an inline component and a full page component that sort of arbitrarily changes its semantics by setting a flag (becoming a full screen view with added details and a close button) would not help to reduce the clutter.Instead, I decided to consolidate functionality in the basic
Account
component which was then also used inAccountInfo
andPaymentInfoLine
to remove some code duplication. Additionally, the account renaming screen in the new designs will be straight forward to implement with the already existing label editing functionality in theAccount
component.Also some demos have been refactored / consolidated / made more interactive by adding knobs.
Lastly, the
AccountInfo
component was renamed toAccountDetails
to avoid confusion with theAccountInfo
interface we have in the account manager.