Acceptable circular reference counts?
Currently within convex i have 20 circular references with 14 that appear with a _generated/api.d.ts (34 total).. Do the references related to api.d.ts have the potential to cause problems?
I still have some refactor ptsd after having to redesign a lot to get it down from over 60 in october. Its not easy to tell where the tipping point is until stuff breaks and it can get very weird.
Its also been keeping me from redesigning the final execution part of our event system for easier use.
The biggest issue right now is composing events, as a event can spawn sub-events within the same mutation (within any ts function atm) and one simple hack is to use the new sub-mutations via ctx.runMutation which will break the chain. I'm just really unclear about the performance downsides, or other issues. Especially since i haven't hardly seen them mentioned, it feels like a cheap hack..
4 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
Did you ever figure this out @ampp ? I've been trying to work through circular dependencies for a few days now and some of them are tricky as hell and i can't figure out a solution
It would be nice if there was more documenation especially on large codebases of organization best practices
Circular dependencies can often surface in lots of places due to a single root cause. You'll want to figure out which
ctx.run* calls are not accompanied by type annotations.
RE: using ctx.runMutation from a mutation - that method is calling a separate function withiin a function, so there's inherent overhead there. ctx.runMutation was added to the mutation context to support Convex Components, and aren't yet intended for other use cases as far as I'm aware.I was using using madge to view them. I'd delete the convex folder to rule out a few of them. Since our design takes the most inspiration from ai-town as far as a code structure i tried to mimic that. I'm assuming some thought was put into it.
My design and needs are so far different than anything that i see its a bit hard to share. I've spent hours implementing some things only throw away everything over a seemingly unfixable circular reference. And a few months later make the same change forgetting that i had to do a work around.
The easiest practice is usually keeping convex react functions in separate files.
I've posted other things like never import functions into 'use node' files from anything, those are some of the most confusing errors to track down.
ctx.runMutation() is by far the easiest way to break up things.
Other than the 10ms~? performance issue, i don't know of anything beyond that.
I get a little nervous that our mutations may be reading 5-10 tables to just write to 1-3 that will bite me bad if it gets any load despite trying very hard to keep it minimal. It would be nice to see how some production customers have had to compensate over time.