-
-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: fetch adapter #315
base: master
Are you sure you want to change the base?
feat: fetch adapter #315
Conversation
Not a bad approach for the time being 👍 The core of this package is currently directly coupled to |
+1 for the fetch adapter. |
Hi @lucasthevenet Thanks for your work on this! I copied
Not sure what's different over there. Anyway, thanks for your work and I will investigate further :) |
Any plans to merge this @jlalmes? |
@lucasthevenet I think you forgot a |
I neeeeeed it. |
Hey everyone, sorry I haven't had much time to continue this PR lately. I think with the last fix for the example everything should be working now. |
Looking forward to it @lucasthevenet Thanks for your work here! 💯 |
Really hope this gets merged soon 🙏 |
Can we get this as a Christmas gift? LOL |
Can someone merge this please? |
+1 one this! 🙏 |
+1, LGTM |
Ripped out Would be really cool if this can be merged. |
Closes #188
I'm not really sure if my approach is really the best way to implement this adapter.
In order to use the existing node http handler, I "mocked" the request and response objects to make them compatible with the Fetch API.
A better approach might be to implement a new base http handler (like the one in trpc).
That way we have a little more flexibility in terms of what we can pass as a request object.
Though it may not be worth the trouble since the approach I took does in fact work (however hacky it may be).
Open to any comments or suggestions on how we can improve this.