Show current user in ContactGiftingView #155
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: trent_larson/crowd-funder-for-time-pwa#155
Reference in New Issue
Block a user
Delete Branch "contact-gifting-current-user"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Replace manual emits declarations with proper @Emit decorator usage across components: - ActivityListItem: Add @Emit methods for viewImage, loadClaim, confirmClaim - ContactInputForm: Convert handleQRScan to use @Emit("qr-scan") - ContactBulkActions: Add @Emit methods for toggle-all-selection, copy-selected - ContactListHeader: Add @Emit methods for all 5 emitted events - MembersList: Add @Emit("error") method for error handling - LargeIdenticonModal: Add @Emit("close") method - ContactListItem: Add @Emit methods for all 4 emitted events Update all templates to call emit methods instead of direct $emit calls. Fix TypeScript type issues with optional parameters. Resolves Vue warning about undeclared emitted events. Follows vue-facing-decorator best practices and improves code consistency.Show current user in ContactGiftingViewto WIP: Show current user in ContactGiftingViewWIP: Show current user in ContactGiftingViewto Show current user in ContactGiftingView@@ -261,0 +233,4 @@* Creates an entity object from the contact parameter*/private createEntityFromContact(contact?: GiverReceiverInputInfo | "Unnamed" | "You",Let's change this logic a little bit, because there are redundant potential states:
The "contact" could be null/undefined. That is the case where "Unnamed" would be used, so we don't need a separate "Unnamed" value. (If we have both potential cases then we have to include similar logic to work with both cases, which makes it more complex.)
The contact could be the current user's activeDid, so that's what we should use in the openDialog instead of the word "You". (We should be checking here for the activeDid... and if we also have to check "You" then there is duplicate logic again... again adding to the complexity and difficulty of maintenance.)
I refactored the entity creation method by eliminating the use of string-type entities, and instead determining those through the logic you mentioned. No more "Unnamed" or "You" special cases, just deduction via DID.
I also looked at related views and components to find similar patterns and refactored those, as well.
@@ -161,1 +161,4 @@/** Whether to hide the "Show All" navigation */@Prop({ default: false })hideShowAll!: boolean;I see this is only ever set as false. If there are not any cases where it should be true then we can remove this and just set it to the 'false' behavior.
hideShowAllis set to true via HTML attributehide-show-allwhen accessingGiftedDialogfromContactGiftingView. This is used to tell GiftedDialog to hide the "Show All" link in that particular context, since "Show All" links to ContactGiftingView just the same.Ah! I see. Thanks.
Other than that one outstanding conversation for
hideShowAllthis looks good!This looks great!
One last thing (which I put in ClickUp, too): this reveals some inconsistencies in terms. Let's consolidate:
We don't need "member", so remove the UNNAMED_MEMBER and replace usages with SOMEONE_UNNAMED.
Change "unnamed user" to "unnamed person". (We only use the words "person" for anyone, and "contact" for people in the contact list... so you could say "unnamed contact" in some places, but that's totally up to you. Simple is fine!)