useContext hook instead of current FnContext prop-drilling

[lefnire]

I'm currently passing FnContext, which includes the user, userId, handleReq/Res, etc. It's wildly unruly. I should use the SST Hooks system to create a useContext hook to be called in where necessary. We should also consider any other helpers from the SST clients to reduce existing boilerplate code.

The Hooks system doesn't have good documentation, so we'll need to look at their code to see how it's used. It should be easy, just no docs is all.

[bmraubo]

👋 Hello there, this project looks cool - could have a crack at this over the weekend.

[lefnire]

@bmraubo Woo! First Github engagement since what, 2020? I'd be happy to do a video chat and show you the ropes if you want. The other tickets I think newcomers would have fun with are #160 and #161 - not only because they're fun to play with, but much of the work doesn't require setting up Gnothi locally.

As for this ticket, here's a bit of a rundown. There are a lot of objects which are fetched at various stages of the request/response cycle. Most obvious being the user object (header.jwt -> cognito lookup -> user lookup); the other being the DB itself, since it's initialized async so can't be imported as-is. So I'm prop-drilling all these objects through the flow manually, which makes from some REALLY ugly code, and is also error-prone. SST has this Hooks system which they use for their session/cookie management helpers. Unfortunately they don't document it, so you'd have to just look at the code - but when I looked, it was dirt simple. This allows you to use useContext() anywhere you need user or db or whatever.

Related to this ticket is I have handleReq and handleRes being passed around. These let routes manually trigger responses via handleRes (rather than leaving it to the return-value process) on an as-needed basis. It also allows requesting a re-fetch via handleReq, as in "I'm not going to handle this, but just do the thing you normally do if they made a request". Anyway, there's no reason these should be added to the context object; they could just be imported standalone, and they can use the useContext() for an variables they need

[bmraubo]

Cool, thanks! I'll reach out if there is any trouble, but the explanation seems clear - much appreciated.

[bmraubo]

Couple set up problems, most of them I have managed to resolve - but one is still giving me trouble: on npm start in root dir, I get Error: Could not resolve context values for (account info). Debug logs show that the relevant cdk info is being obtained, but not saved to file - although I get a publishing event for cdk.context.json:

2023-07-02T19:58:54.369Z     +0ms [debug] Publishing event {"type":"file.changed","properties":{"file":"/Users/bartoszraubo/Documents/my_projects/gnothi/cdk.context.json","relative":"cdk.context.json"},"sourceID":"eef5450b11919bf46bb78237ace7d1e3"}

There is a further cdk.context.json file in the .sst dir, and manually plugging in some of the values there seems move things along slightly - but better to find the route cause rather than some hacky override.

Have you encountered anything similar? Have not found anything going through SST issues or their Discord.

[lefnire]

I haven't seen this. I wonder how much of the stage/profile is tied to any literal words "gnothi". This might be a good vid-chat, but I'll do some poking around offline as soon as I can.

[bmraubo]

Might have been caused by the changed I made to get preceding errors sorted too. I would be up for a call, but we do have a time zone issue - I am near London, you're West Coast, I believe? I will be in Chicago Thursday-Sunday which should make that easier though.

[lefnire]

Hit me up at tylerrenelle gmail, if you're up for it while Chicago-bound. No worries if it's too much; already above & beyond you're looking in the code trying to make things work.