Delete button in right drawer / side pannel

[ehconitin]

fixes #7069
@Bonapara

2024-09-23.17-42-55.mp4

[greptile-apps]

PR Summary

This PR adds a delete button to the right drawer/side panel of the show page, addressing issue #7069 by allowing users to delete notes/tasks directly from the side panel.

• Implemented delete functionality in packages/twenty-front/src/modules/ui/layout/show-page/components/ShowPageRightContainer.tsx
• Added a styled component StyledButtonContainer for consistent button placement
• Utilized useDeleteOneRecord hook for record deletion
• Conditionally rendered the delete button when the component is in the right drawer
• Improved user experience by enabling quick deletion without navigating to the Notes object list

_{1 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings}

[bosiraphael]

Hello @ehconitin ! It seems that the trash Icon is missing in the button ;)

[ehconitin]

@bosiraphael oops, I am yet to finalize changes Raphael.
In #7168, I think I forgot to remove code which was to be addressed in that PR itself. I dont know how I missed it.
That issue needs to be addressed!
So right now I am thinking of a way I could handle that in this PR as these both buttons have similiar styles.
Ill tag you once done

[bosiraphael]

Left some comments :)

[bosiraphael]

@bosiraphael oops, I am yet to finalize changes Raphael. In #7168, I think I forgot to remove code which was to be addressed in that PR itself. I dont know how I missed it. That issue needs to be addressed! So right now I am thinking of a way I could handle that in this PR as these both buttons have similiar styles. Ill tag you once done

Okay no worries! When you are still working on your PR, you can open a draft PR instead, or just add the label WIP :)

[ehconitin]

@bosiraphael oops, I am yet to finalize changes Raphael. In #7168, I think I forgot to remove code which was to be addressed in that PR itself. I dont know how I missed it. That issue needs to be addressed! So right now I am thinking of a way I could handle that in this PR as these both buttons have similiar styles. Ill tag you once done

Okay no worries! When you are still working on your PR, you can open a draft PR instead, or just add the label WIP :)

@bosiraphael yup yup, will take a note of it for next time :)

[ehconitin]

@bosiraphael
for command menu to be alligned for mobile devices we do this, so should I follow the same pattern or having navigationBar height state makes more sense, so that we dont have to hardcode this value each time?

[bosiraphael]

@bosiraphael for command menu to be alligned for mobile devices we do this, so should I follow the same pattern or having navigationBar height state makes more sense, so that we dont have to hardcode this value each time?

I think the issue of the button being missaligned has something to do with the ShowPageRightContainer not being the right size, I don't think a state is the correct pattern but you can use a constant if you find it useful :)

[ehconitin]

@FelixMalfait
I narrowed down the issue, useDeleteOneRecord was not refetching queries like useRestoreManyRecords does.
I followed the same pattern from useRestoreManyRecords and it worked but within useRestoreManyRecords there is a comment above those refetch queries

 // TODO: fix optimistic effect
      const findOneQueryName = `FindOne${capitalize(objectNameSingular)}`;
      const findManyQueryName = `FindMany${capitalize(
        objectMetadataItem.namePlural,
      )}`;

2024-09-25.18-10-15.mp4

[ehconitin]

@bosiraphael
This is correct right? this is regarding the height of the right drawer.
Should i just use a local const like in CommandMenu? or create new const file and export it from there to both the files

[bosiraphael]

Second option is better to avoid code duplication :)

[FelixMalfait]

@ehconitin yes re-fetching is not a best practise, it throws an additional request to fetch the resource again, while we should instead be able to optimistically predict the result and modify the cache based on that

[ehconitin]

Hi @FelixMalfait, I don't have much expertise in this area, unfortunately.

@bosiraphael, could you assist with this? For more context, please follow the comment thread here.

[FelixMalfait]

As discussed in Discord, since we introduce Soft Delete, the delete isn't really a delete anymore, so we should instead leverage what's been done for optimistic updates when there's a delete, as what we call "delete" is actually closer to an update.
We should keep the code for optimistic delete but instead rename it and use it in the case of "destroy" (our internal name for "hard deletes")

[ehconitin]

@FelixMalfait Understood, I am still thinking about it :(. Ill get back to you!

[ehconitin]

Hey @FelixMalfait ,
So, I've worked on the soft delete thing, but I went about it a bit differently than we initially talked about. Here's what I did:

I tweaked useDeleteOneRecord:

It's now using updateOneRecordMutation instead of delete.
It just adds a deletedAt timestamp for soft deletion.

I kept triggerDeleteRecordsOptimisticEffect:

I didn't rename it, but I removed the cache eviction step.
It now hides soft-deleted records from queries instead of totally removing them from the cache.
Not using cache.evict, so deleted records stay in the cache but don't show up.

I didn't create a new triggerDestroyRecordsOptimisticEffect or use triggerUpdateRecordOptimisticEffect because:

Our current triggerDeleteRecordsOptimisticEffect already does a good job with cache updates for soft deletes.
It handles all the related records and query stuff we need.
Switching to triggerUpdateRecordOptimisticEffect would mean rewriting a bunch of stuff to handle how we remove things from queries.

What I'm thinking for next steps:

For hard deletes, we should use cache.evict in combination with useDestroyOneRecord to completely remove the record from the cache.
Maybe rename and handle cache eviction in triggerDeleteRecordsOptimisticEffect to something that fits both soft and hard deletes better.

Let me know what do you think!
This code works as expected for soft deletes but do let me know if I am missing anything.
Thanks :)

[FelixMalfait]

@ehconitin sorry but I don't think that's a right approach. There's a reason why there's a "delete" endpoint on the backend, for example we trigger webhook events or can cascade upon deletion. I'm not sure updating deletedAt through the update mutation should be allow at all, it's more a result of our lack of mechanism to prevent this than an active choice.

[ehconitin]

@FelixMalfait
I think I got it!
I fixed the deleteOneRecordMutation in useDeleteOneRecordMutation. Instead of just asking for { id } after deleting, we now use mapSoftDeleteFieldsToGraphQLQuery(objectMetadataItem). This new function grabs all the fields we need for a soft delete, ie., id and deletedAt.

Also I havent yet renamed anything!
What do you think?

[FelixMalfait]

Thanks a lot @ehconitin! Our implementation still not perfect but I feel like it's already better than we have today so we should merge! (I just did a small edit).

@bosiraphael is working on unifying the action framework so he will refactor that code a bit after it's merged and maybe it'll improve so remaining edge cases (e.g. the fact that on list view we show "delete" and not the destroy action even when viewing the deleted records)

[github-actions]

Thanks @ehconitin for your contribution!
This marks your 40th PR on the repo. You're top 1% of all our contributors 🎉
See contributor page - Share on LinkedIn - Share on Twitter