too_easy
too_easy
CCConvex Community
Created by too_easy on 11/26/2024 in #support-community
[Resolved] - TypeError: Cannot destructure property 'signIn' of useAuthActions
Using @tanstack/start and when I go to create a signin component:
import { useAuthActions } from "@convex-dev/auth/react";

const Signup = () => {
const { signIn } = useAuthActions();

return <div>Hello</div>
}
import { useAuthActions } from "@convex-dev/auth/react";

const Signup = () => {
const { signIn } = useAuthActions();

return <div>Hello</div>
}
Get the error:
Error in renderToPipeableStream: TypeError: Cannot destructure property 'signIn' of '__vite_ssr_import_1__.useAuthActions(...)' as it is undefined.
Error in renderToPipeableStream: TypeError: Cannot destructure property 'signIn' of '__vite_ssr_import_1__.useAuthActions(...)' as it is undefined.
Also seems that my IDE can't pick up and autocomplete useAuthActions either?
6 replies
CCConvex Community
Created by too_easy on 11/25/2024 in #support-community
ConvexAuthNextjsServerProvider not exported
From the docs for NextJS (https://labs.convex.dev/auth/setup): Wrap your app in ConvexAuthNextjsServerProvider from @convex-dev/auth/nextjs/server But ConvexAuthNextjsServerProvider is not exported from @convex/auth package in v0.0.74. Means that a bunch of the NextJS steps including, I presume, middleware are not achievable as the docs say?
12 replies
CCConvex Community
Created by too_easy on 11/25/2024 in #support-community
How to use convex in a big team/monorepo
Let’s say I’ve got a relatively large project with my team of let’s say 15 devs. This project consists of multiple frontend apps and multiple “services”. The model I’ve been working with for some time is an NX integrated monorepo (ie shared package.json) with NestJs micro services (graphql or grpc). Chuck pulumi or sst in there to deploy each deploy target. Now the upside of this model is that you can establish unique deployment targets for each service and frontend, seperate databases by concern/domain and scale each part of the project independently. With local development you can have each developer using local db instances to test new schemas in isolation (ie not impacting the work of other devs). The downside of this model is that wire up is incredibly cumbersome and time consuming, the number of integrations needed to support realtime, file storage etc.. is time consuming, and get full end to end type safety is nothing short of a burden. I can see convex solving a heck of a lot of these integration and type safety problems, however it is unclear how convex is supposed to scale out as a developer experience with multiple devs working on a project at once? Firstly, having a single “dev” environment - do all developers working locally use this one environment? How do they not step on each other’s toes with schema changes? Second - is it possible to have multiple (neatly managed) convex instances acting as separated concerns in the one project? Third - deployment to a personal environment for testing / PRs and spinning up a local environment just for the one developer before push to dev, staging and then prod? I’d love to start using convex on some large scale stuff but it’s hard to get the team over the line without having clearer patterns recommended by the convex team. Appreciate your feedback!
14 replies