-
Notifications
You must be signed in to change notification settings - Fork 484
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
SCP-2092: Implement new design of contract cards. #3556
Conversation
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.
Looking good🦄
handleAction _ (SetNickname nickname) = do | ||
handleAction { followerAppId } SelectSelf = callMainFrameAction $ MainFrame.DashboardAction $ Dashboard.SelectContract $ Just followerAppId | ||
|
||
handleAction { followerAppId } (SetNickname nickname) = do |
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.
We are not using the app id here right?
handleAction _ (SetNickname nickname)
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.
yes, we need it to insertIntoContractNicknames
(contractNicknames is a Map PlutusAppId String
)
, type_ InputText | ||
, value nickname | ||
, onValueInput_ SetNickname | ||
, placeholder "Please rename" |
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 the Please rename
something for us internal to remember we have to rename? if so, it's probably worth to add a FIXME. If it's for the end user we might want to ask Niahm for some copy
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 isn't a note for us - this is the text Russ included in his designs
3fd0ef7
to
3596af5
Compare
3596af5
to
8960485
Compare
This implements the new designs for the dashboard, with the contract summary cards including the actions possible at the current step. I haven't changed the style of the actions themselves, since that change also applies to the current step card on the contract screen - and I'll attack the contract screen in the next PR. This PR already feels quite big enough, especially the diff of the Contract.View module.
Until now, the
selectedContractIndex
in theDashboard.State
was doing two things: determining which contract screen was visible, and also which contract anyContract.Action
applied to. In the new designs, aContract.Action
for any contract can be called from the dashboard, without the need to first go into the screen for that contract, so these two things needed to come apart. I left theselectedContractIndex
to determine which contract screen is visible, and added an contract index (PlutusAppId
) parameter toContractAction
.While I was at it, I deleted the
followerAppId
from theContract.State
, which is duplicate information already available as the key of the contract map in theDashboard.State
. Instead I'm passing this asinput
to the contract action handlers, which feels nicer. And because the contract view needs to know about this, I changed the partitioned arrays of contracts (running / completed) to maps. Since the filter functions are being called every second, we might want to store these as separate maps in the sate - but I haven't noticed any performance issues yet, so I'm not too worried about it.