Closed dteare closed 6 months ago
I suggest we take the simpler approach for now and go with the exclusion file approach. Something along the lines of:
generate -i example-handlers -o k7.ts --exclude-types request_guards
Where request_guards
would be a user-provided file of line separated types they want to ignore. They'll always be request guards in my mind but perhaps there will be other situations where someone would want a type to be excluded. Hence the exclude-types
parameter name.
I've addressed the issue -- I realised I made a mistake by branching from my own Main branch. So when you merge the previous pr i will open this new one. So you don't get overwhelmed due to the prev changes. 😅
I've addressed the issue -- I realised I made a mistake by branching from my own Main branch. So when you merge the previous pr i will open this new one. So you don't get overwhelmed due to the prev changes. 😅
Oh looking forward to seeing the approach you used.
Re: branching, it does get a bit tricky managing multiple branches. It certainly helps on the PR review side of things so try to do so when reasonable. It is a balance though so if you find yourself juggling too many of them then feel free to push back. The main thing is to clearly communicate your changes.
When generating our TypeScript interface we should omit Custom Request Guards as the client doesn't need to think about these.
For example,
example-handlers/thread.rs
includes anAgentService
that is provided to us automatically by Rocket. SinceAgentService
implementsFromRequest
, Rocket has all it needs to construct this from the request itself (usually an user auth header or similar) and so the client doesn't need to include it explicitly in their request.~Ideally we'd detect when types implement
FromRequest
and ignore them.~ If that turns out to be overly difficult I suggest we add a CLI parameter for specifying a file containing type exclusions. We could default to skipping types likeDb
andState
.