Clever Tagline
Clever Tagline
PostsComments
CCConvex Community
Created by Clever Tagline on 2/26/2025 in #support-community
Sharing an array between Convex and UI?
I probably should have mentioned this, but this project is a monorepo (Turborepo specifically), with the Convex functions in a package that's separate from the app. Accessing the Convex stuff from within the app is all done via the package prefix; e.g. import { Doc } from "@loaportal/backend/convex/_generated/dataModel" . If I put this array in a file named something like shared.ts inside the convex folder and provide access to it by defining a path in the package exports, would that work?
10 replies
CCConvex Community
Created by Clever Tagline on 2/26/2025 in #support-community
Sharing an array between Convex and UI?
I'm not sure I understand your comment about the 500% cache hit rate. Is that good or bad?
10 replies
CCConvex Community
Created by burnstony#1975 on 2/25/2025 in #support-community
pagination
(I'll be offline the rest of the night, but I'll check back tomorrow)
53 replies
CCConvex Community
Created by burnstony#1975 on 2/25/2025 in #support-community
pagination
Could you describe your use case in more detail? How many documents are in your table?
53 replies
CCConvex Community
Created by Clever Tagline on 2/26/2025 in #support-community
Sharing an array between Convex and UI?
I tried searching the docs/Discord for anything about this but came up empty
10 replies
CCConvex Community
Created by Clever Tagline on 2/21/2025 in #support-community
Advice re: schema design for user-specific role-based properties
Looks like I'm going back to individual fields for specific role settings. Trying to keep a user settings object updated as roles change is proving to be a much bigger headache than I imagined it would be.
13 replies
CCConvex Community
Created by Clever Tagline on 2/21/2025 in #support-community
Advice re: schema design for user-specific role-based properties
This definitely looks promising...
13 replies
CCConvex Community
Created by Clever Tagline on 2/21/2025 in #support-community
Advice re: schema design for user-specific role-based properties
The farther I go into this, the more I feel like I need to back away from the "make it work for every use case" approach, as it's just adding complexity and time that we can't afford right now.
13 replies
CCConvex Community
Created by Clever Tagline on 2/21/2025 in #support-community
Advice re: schema design for user-specific role-based properties
And I'm the lone dev
13 replies
CCConvex Community
Created by Clever Tagline on 2/21/2025 in #support-community
Advice re: schema design for user-specific role-based properties
Funny you should mention a form for new roles... (yes, I've already made one) For now, this is being designed for our own company, and our current roles are pretty well-defined. However, the owner has grand plans for taking what I build and eventually marketing it as a product that others can purchase and use for other types of service businesses. That's been my big struggle with anything I'm doing: make it work for us and our current needs, but also make it somewhat flexible so that it can work for his Grand and Glorious Plan™️
13 replies
CCConvex Community
Created by Clever Tagline on 2/21/2025 in #support-community
Advice re: schema design for user-specific role-based properties
The roles table is meant for global data about roles, though—e.g. only one "Salesperson" role record exists—and the users table has a "roles" field defined as v.optional(v.array(v.id("roles"))). Going back to my brainstorm above, my thought was that if I find the ID for the "Salesperson" record in this "roles" field, I should expect to find a key in this theoretical object that's the ID of that role, with the value being a known settings object matching a certain format. Your suggestion (minus the "user" field) would work for creating defaults for those settings, but I feel the user-specific values should live on the user's own record. I just can't think of a way to do that so that I could collect the data and have the types known in advance; i.e. using your example, know that "commission" is a number, "rank" is a string, etc. Or are you saying that by defining the settings object in the original record in "roles," I could use that to infer the type elsewhere? I keep thinking that v.record could be used somehow, but I don't fully understand it. Would something like this work as a validator for a field? 
v.record(v.id("roles"), v.union(
  // Salesperson settings
  v.object({
    commission: v.number(),
    rank: v.string()
  }),

  // Another role
  v.object({
    canDoStuff: v.boolean()
  }),
  ...
))
v.record(v.id("roles"), v.union(
  // Salesperson settings
  v.object({
    commission: v.number(),
    rank: v.string()
  }),

  // Another role
  v.object({
    canDoStuff: v.boolean()
  }),
  ...
))
13 replies