Any news on this?!

Hi @mammadataei, I'm a bit stuck on keeping the context type in tact for the operations when they're destructured. I've moved the work to a typescript playground to iterate more quickly with all the types in one place. Take a look at the playground, let me know if you have any ideas. Essentially, the types get lost in the createBoundOperations function, but in the example boundCreate works when it's done directly on the operation function.

@mammadataei Okay, I got it, but it's super messy and I'm not sure which parts are required. I'll have to do a few passes to clean it up, there's a quite a bit here that's outside my understanding.

@chadian Hi again, sorry I've been busy recently. I've checked your playground, and I have no idea what's going on! I'll try to read the source code to learn how it's working; I hope I can help better. Any suggestion on where should I start?!

Hi @mammadataei, all good! I think I know how it's working in the playground, essentially type parameters need to be destructured next to each other to get the underlying type inference, and by not setting default types or passing any in. I've just updated the PR and I need to add some tests using https://github.com/SamVerschueren/tsd and I think it'll be good to go.

I thought I had it in the playground, and it's pretty close, but it's missing some sort of inference in the transaction and being bound with the operation context. I've whittled it down a more representative example with samples of what should and shouldn't pass in this playground.

What is working here is the types on the store when reading values eg paper.data.Book but not in the mutate callback await p.mutate(({ create }) => create('Book')); where in both cases "Book" should be inferred by a SchemaType definition with Book in it.

This website offers some insights into what's required to get this working. It's just the multiple levels of passing these types that I'm missing something.

Note to self: try bumping typescript and using satisfies.