Create and fetch new database entities
Hi, I'm solving implementing this feature (https://github.com/twentyhq/twenty/issues/4199).
I'm trying to follow the tips that Felix left in the issue thread. So far, I was able to add a new column,
everyone
to the messageThread
table. After that, I've also created a new table (by table im referring to the object-metadata.ts
files, and the repositories) name d MessageThreadMembers
, with two columns for the MessageThreadId
and WorkspaceMemberID
. I used psql to query my local database and all the tables and FK constraints were working fine.
Now, here is where im stuck: I'm trying to fetch the workspace members of a message thread, so the frontend can consume that information and use it for the message thread members chip/dropdown that I'll eventually code it aswell. I've tried a diverse combination of things here, using how the fetching of MessageThread
works as a reference. My workflow here was something like: Add the necessary export types
in the graphql.tsx
file inside twenty-chrome-extension/src/generated
folder -> create fetchAllThreadMembersOperationSignatureFactory.ts
-> create a new hook that uses useFindManyRecords
and add an entry in CoreObjectNameSingular
.
Sorry for the wall of text, I tried to explain my current situation the best I could.
I'm not sure if Im moving in the right direction, I only worked with REST APIs before, so this Graphql world is very different from what I am used to.
Can someone point me in the right direction on how I can fetch entities from the database/backend so I can use them in the frontend?
Thanks in advanceGitHub
Issues · twentyhq/twenty
Building a modern alternative to Salesforce, powered by the community. - Issues · twentyhq/twenty
10 Replies
Hi @pereira, first, thanks for taking the time to contribute 🙂 This is a tricky one!
When a thread is opened in the Right Drawer, a FindManyMessages query is sent. This one is built through the useFindManyRecords in useRightDrawerEmailThread.
you can query the your MessageThreadMembers participants by passing them in recordGqlFields parameter of useFindManyRecords, so adding them to fetchAllThreadMessagesOperationSignatureFactory fields
(operation signature is there just to ensure that useFindManyRecords is always called with same parameters, this is useful to cache query results and avoid useless queries)
You'll also need to have created the relation between your new Standard object (Message Thread Members) and the existing Message Thread Member
To do that, you would need to play with files such as message-thread.workspace-entity.ts
and apply changes by running:
npx nx run twenty-server:command workspace:sync-metadata -w {workspaceId} -f
Now, regarding the list of emails as you'll probably also want to change the visilibity of shared emails there, we could not leverage useFindManyRecords as we don't support nested query filters yet. We were forced to make a custom endpoint. Here, you'll just need to manually change the query
Sorry, it's really badly documented at the moment, feel free to open an incomplete PR and we can help you directly on it
thanks so much @charles! I still have some questions:
1- I already created the relations between MessageThreadMembers (a new table that we created, it doesnt exist yet) and MessageThread and WorkspaceMember (two FK).
To apply the changes, I've been using
npx nx database:reset twenty-server
. Do I still need to run npx nx run twenty-server:command workspace:sync-metadata -w {workspaceId} -f
if I'm resetting the database?
2- Regarding the graphql files, I am not sure if I should be manually editing them. Searching through old discord messages, I am now aware that they seem to be auto generated. However, I am not sure of the commands to generate them, and which ones I am supposed to generate, as there are 3 different graphql files (one in twenty-chrome-extension
and two in twenty front (graphql.ts
and graphql.tsx
.
I will keep working on this the best I can, If I get really stuck (probably on the step to visibility of the thread itself), I'll open the PR like you suggested. Thanks once again :)1- no need if you reset, indeed!
2- for the useFindManyRecords (right drawer case), you don't need to edit those files as it's all dynamaic, for the list you'll need to update the server custom resolver, the front query getTimelineThreadsFromCompanyId, and graphq.tsxl file is auto-generated through:
npx nx run twenty-front:graphql:generate --configuration=data
it will update packages/twenty-front/src/generated/graphql.tsx according to getTimelineThreadsFromCompanyId / getTimelineThreadsFromPersonId@charles it worked :) ! Thanks for the tips, i am now able to fetch everything I need (everyone field from messageThread, and the messageThreadMembers) from the backend with just a few lines added
One last question:
I am fetching the data inside the
RightDrawerEmailThread
component, but, I need to use it in the RightDrawerActivityTopbar
, so I can put change the chip that displays if the thread is being shared and with whom correctly.
I don't want to make the query twice, once inside each component.
My first thought was passing up the data from the RightDrawEmailThread
to it's parent component (RightDrawerRouter
) and then passing it down to the RightDrawerActivityTopbar
, but as the parent component purpose is to serve as a router, I'm not sure if this would be the best approach. Should I build it like this or do you have any different suggestions?You should create a recoil state (createState) and read and write from boths components
I did that, it worked perfectly. Thanks!
Lot's of progress was done. I am wondering if I should write tests. What I've done was create new entities, fetch them, use the value on the frontend and display a chip
Looking like this so far (here, only the owner has access, therefore it's in the private state). I've also done the state everyone, and the state shared with N members
I've been looking at the existing tests and Im unsure of what to add (or if i should add)
we should add unit tests on all the utils and hooks
and add storybook tests on components
I see your PR, let's discuss there!