Skip to content
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

Merged
merged 2 commits into from Feb 2, 2023

Conversation

willm30
Copy link
Contributor

@willm30 willm30 commented Jan 26, 2023

Description

This PR refactors the ActionsListItem to:

a) Use a base ListItem component that can be shared with DecisionsListItem
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
  • Mapping between action types and message descriptor values in en-actions

Changes 🏗

  • Combined SetUserRoles in en-actions and updated formatRolesTitle utility
  • Minor tidying of InputLabel
  • Moved ActionsListItem to ColonyActions since it's no longer a shared component.

Contributes to #207

@willm30 willm30 self-assigned this Jan 26, 2023
@willm30 willm30 changed the base branch from port/colony-actions to port/207-actions-list January 30, 2023 14:48
@rdig rdig mentioned this pull request Jan 30, 2023
3 tasks
@willm30 willm30 force-pushed the port/207-actions-list branch 3 times, most recently from 14f4ce3 to 561ffe1 Compare January 30, 2023 17:54
@willm30 willm30 changed the title Port Actions List Refactor Actions List Item Jan 30, 2023
@willm30 willm30 force-pushed the port/207-actions-list-item branch 2 times, most recently from 88bd902 to 159fc62 Compare January 30, 2023 18:03
@willm30 willm30 force-pushed the port/207-actions-list branch 5 times, most recently from 2010a41 to 0f7853b Compare January 31, 2023 11:01
@willm30 willm30 force-pushed the port/207-actions-list branch 2 times, most recently from 22900e4 to cf77ae5 Compare January 31, 2023 11:22
@@ -41,7 +40,6 @@ const Entry = ({ store }: Props) => {
...actionMessages,
...eventsMessages,
...systemMessages,
...motionMessages,
Copy link
Contributor Author

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 = ({
Copy link
Contributor Author

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 = (
Copy link
Contributor Author

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';
Copy link
Contributor Author

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,
Copy link
Contributor Author

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.

Copy link
Collaborator

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

Copy link
Contributor Author

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

Copy link
Member

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()}
Copy link
Contributor Author

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';
Copy link
Contributor Author

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}`,
Copy link
Contributor Author

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}
Copy link
Contributor Author

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 = (
Copy link
Contributor Author

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)

@willm30 willm30 linked an issue Jan 31, 2023 that may be closed by this pull request
@willm30 willm30 marked this pull request as ready for review January 31, 2023 12:11
@willm30 willm30 requested a review from a team January 31, 2023 12:11
Copy link
Collaborator

@jakubcolony jakubcolony left a 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!

Comment on lines 60 to 61
commentCount: any;
fromDomainId: any;
Copy link
Collaborator

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?

Comment on lines 91 to 94
(values, key) => {
// eslint-disable-next-line no-param-reassign
values[key] = updatedItem[key];
return values;
Copy link
Collaborator

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,
Copy link
Collaborator

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

Copy link
Member

@rdig rdig left a 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.

Comment on lines 20 to 26
titleCommentCount: {
id: `${displayName}.titleCommentCount`,
defaultMessage: `{formattedCommentCount} {commentCount, plural,
one {comment}
other {comments}
}`,
},
Copy link
Member

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,
Copy link
Member

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()}
Copy link
Member

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.

Comment on lines +132 to +135
export type ActionUserRoles = {
id: ColonyRole;
setTo: boolean;
};

Copy link
Collaborator

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

@willm30 willm30 merged commit dc3cef0 into port/207-actions-list Feb 2, 2023
@willm30 willm30 deleted the port/207-actions-list-item branch February 2, 2023 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Port over Actions List component
3 participants