Skip to content
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

[✨] Allow using GET with server$ #5656

Closed
manvalls opened this issue Dec 31, 2023 · 3 comments · Fixed by #6290
Closed

[✨] Allow using GET with server$ #5656

manvalls opened this issue Dec 31, 2023 · 3 comments · Fixed by #6290
Assignees
Labels
TYPE: enhancement New feature or request WAITING FOR: team Waiting for one of the core team members to review and reply

Comments

@manvalls
Copy link

Is your feature request related to a problem?

POST requests are not easily cacheable

Describe the solution you'd like

A way to tell server$ to use GET instead of POST

Describe alternatives you've considered

Considered just using an endpoint, but I love the streaming functionality

Additional context

No response

@manvalls manvalls added STATUS-1: needs triage New issue which needs to be triaged TYPE: enhancement New feature or request labels Dec 31, 2023
@wmertens
Copy link
Member

wmertens commented Jan 1, 2024

Typically I'd cache on the client side in this case.

Doing a GET implies putting the variables in the URL and listening for GET in the handler as well. That latter could be a little bit annoying but probably ok.

I suppose we could do it, what do you think @mhevery ?

@wmertens wmertens added WAITING FOR: team Waiting for one of the core team members to review and reply and removed STATUS-1: needs triage New issue which needs to be triaged labels Jan 1, 2024
@PatrickJS
Copy link
Member

server$ needs a config for other features like changing origin, adding headers, query params etc

@PatrickJS PatrickJS self-assigned this May 7, 2024
@wmertens
Copy link
Member

wmertens commented May 7, 2024

@PatrickJS I propose a default config via the qwik city provider and then maybe the first argument. Right now that can optionally be an abort signal and we could also make it be an options object

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TYPE: enhancement New feature or request WAITING FOR: team Waiting for one of the core team members to review and reply
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants