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 Actions List Item #229
Conversation
2a88811
to
4375158
Compare
4375158
to
4a22db9
Compare
4a22db9
to
8a43f70
Compare
14f4ce3
to
561ffe1
Compare
561ffe1
to
baa6433
Compare
88bd902
to
159fc62
Compare
2010a41
to
0f7853b
Compare
159fc62
to
4c3227c
Compare
22900e4
to
cf77ae5
Compare
6d714d9
to
df68f6f
Compare
@@ -41,7 +40,6 @@ const Entry = ({ store }: Props) => { | |||
...actionMessages, | |||
...eventsMessages, | |||
...systemMessages, | |||
...motionMessages, |
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 seem to have moved away from having two separate files for actions and motions messages, which makes sense since they share the same set of messages, so have removed.
item: FormattedAction; | ||
} | ||
|
||
const ActionsListItem = ({ |
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.
There are two parts to this refactor. First is the abstraction of the view ListItem
, which will also be shared by DecisionListItem
.
The second is handling the logic, most of which was dedicated to formatting the title correctly. This is now handled by getActionListItemTitleValues
.
The commented out sections refer to motions functionality.
}; | ||
|
||
/* Returns the correct message values according to the action type. */ | ||
const getActionListItemTitleValues = ( |
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.
Before we were passing the FormattedMessage
component a massive object with all possible title values. Now we fetch the relevant values, according to the action type, and only pass in those.
All this needs to be maintained is that the mapping above gets updated every time a new message is added at en-actions
.
@@ -0,0 +1,146 @@ | |||
import React from 'react'; |
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 can see this file being merged with config.ts
in the event the data wrangling requirements are simplified (e.g. no async) and we don't have much to handle in the component. But for now I've separated as it makes it easier to see what's going on in config
.
This file is basically just responsible for ensuring that the items object has key value pairs that match what we're expecting in our message descriptors.
|
||
/* | ||
|
||
Note that the following transformations also exist in the Dapp. Because they are async, |
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've left this comment here as a reminder of outstanding transformations that hopefully will be handled by the cdapp equivalent of the actions resolver.
Can't do anything in this pr since we're using mock data.
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.
Local resolvers are a deprecated feature, so custom hooks sound like the best next option
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.
@jakubcolony Or have all/most of the transformation handled by the block ingestor? I.e. it picks up the on-chain event and adds to the db an actions item that's as close as possible (minus the jsx) to the format expected by the actions list item. (E.g. providing a User object instead of an address string). Then we query the db for that action to display in the list.
Isn't that more or less the flow we're expecting to implement anyway?
cdapp => on-chain event => block ingestor => db => cdapp
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.
That's kinda the general idea of the block investor anyway, to handle as much data processing as possible, so we can offload it from the client.
Granted, this is not possible in all cases, but where that's the case, we should strive to achieve that.
> | ||
<div | ||
className={styles.avatar} | ||
onClick={(e) => e.stopPropagation()} |
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 when you click on the avatar it doesn't fire the parent div's click event
@@ -1,80 +0,0 @@ | |||
import { isEmpty } from 'lodash'; |
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 doesn't need to be a hook any longer so moved to ~utils/colonyActions
other {Generic action we don't have information about} | ||
}`, | ||
[`action.${ColonyActions.SetUserRoles}.assign`]: `Assign the {roles} in {fromDomain} to {recipient}`, |
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.
Simplified these. Exact text is handled by formatRolesTitle
in ~utils/colonyActions
'action.type': `{actionType, select, | ||
${ColonyActions.WrongColony} {Not part of the Colony} | ||
${ColonyActions.Payment} {Payment} | ||
${ColonyMotions.PaymentMotion} {Payment} |
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.
Added motions here since they've already been added to action.title
(which I think is a good idea since actions and motions share the same messages)
@@ -51,6 +50,26 @@ const isMessageDescriptor = (message?: Message): message is MessageDescriptor => | |||
|
|||
const { formatMessage: formatIntlMessage } = intl<ReactNode>(); | |||
|
|||
const addKeyToFormattedMessage = ( |
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.
Required when complex message values are included in a component that is part of a list (e.g. actions list item)
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.
LGTM, great idea with abstracting this!
commentCount: any; | ||
fromDomainId: any; |
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 better types be provided here?
(values, key) => { | ||
// eslint-disable-next-line no-param-reassign | ||
values[key] = updatedItem[key]; | ||
return values; |
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 this be rewritten so that it doesn't mutate the values
(meaning we can get rid of the rule disable)?
For example:
return {
...values,
[key]: updatedItem[key]
}
|
||
/* | ||
|
||
Note that the following transformations also exist in the Dapp. Because they are async, |
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.
Local resolvers are a deprecated feature, so custom hooks sound like the best next option
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.
Very nice work again.
Left some comments, one of which requires attention, but other than that, it's good to go.
titleCommentCount: { | ||
id: `${displayName}.titleCommentCount`, | ||
defaultMessage: `{formattedCommentCount} {commentCount, plural, | ||
one {comment} | ||
other {comments} | ||
}`, | ||
}, |
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 won't have comments enabled for the initial launch.
So either remove these, or just comment them out
|
||
/* | ||
|
||
Note that the following transformations also exist in the Dapp. Because they are async, |
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.
That's kinda the general idea of the block investor anyway, to handle as much data processing as possible, so we can offload it from the client.
Granted, this is not possible in all cases, but where that's the case, we should strive to achieve that.
> | ||
<div | ||
className={styles.avatar} | ||
onClick={(e) => e.stopPropagation()} |
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.
Shouldn't this be handled inside a callback ?
This is because, having it like this, will instantiate 2 new anonymous functions on every render and subsequent re-renders.
Having it as a callback instantiates it just once.
export type ActionUserRoles = { | ||
id: ColonyRole; | ||
setTo: boolean; | ||
}; | ||
|
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 you clean up the imports in this file? They still contain the old ~core
or ~data
df68f6f
to
a2e8912
Compare
Description
This PR refactors the
ActionsListItem
to:a) Use a base
ListItem
component that can be shared withDecisionsListItem
b) Handle all the title-related logic outside the component.
Testing
More of a straight-forward code review, just make sure the ActionListItem works the same as in #231.
New stuff ✨
ListItem
en-actions
Changes 🏗
SetUserRoles
inen-actions
and updatedformatRolesTitle
utilityInputLabel
ActionsListItem
toColonyActions
since it's no longer a shared component.Contributes to #207