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

[💫 Feature Request ] Allow SSE to use POST /w payload #139

Open
XChikuX opened this issue Jan 24, 2025 · 5 comments
Open

[💫 Feature Request ] Allow SSE to use POST /w payload #139

XChikuX opened this issue Jan 24, 2025 · 5 comments

Comments

@XChikuX
Copy link

XChikuX commented Jan 24, 2025

There is no technical reason to prevent SSE from sending a POST request or limiting the API to be payload-less

This issue is a very modest request to allow more advanced payloads for SSE.

I looked for existing implimentations and found This

I've already integrated it as an EventSource drop-in replacement to SSE and it works great.

Upon adding a payload (namely a captcha) and making it a POST request, everything works as expected and is very stable.

Would it be possible to integrate htmx 2.0 SSE extention with this solution?

Check https://dbounce.me (Bulk verification) for a working example.

@Telroshan
Copy link
Collaborator

Hey,

There is no technical reason to prevent SSE from sending a POST request or limiting the API to be payload-less

I would theoretically agree with you as the HTML standard doesn't define which HTTP method should be used, but for us, standard API users, there actually is a technical reason here : we can't specify which method the EventSource should use, it's simply not a configurable property at all unfortunately :/

The SSE extension uses the standard SSE implementation, while the one you linked states itself at its beginning:

A flexible EventSource polyfill/replacement

So it's a replacement, a workaround, and not using the standard SSE implementation at all.
While I understand your functional needs here, I think this would be better as a separate community extension rather than replacing the current one which we want to rely on standard APIs as much as possible. I hope you'll understand our concerns about that!

So, if you are interested, feel free to dive into making an extension for this SSE polyfill, and submit it in our community extensions list

@Telroshan Telroshan added new extension and removed enhancement New feature or request labels Jan 25, 2025
@XChikuX
Copy link
Author

XChikuX commented Jan 25, 2025

If it walks like a duck and quacks like a duck?

It says, it's a drop-in replacement for EventSource with additional functionality.

Meaning it will default to expected protocol behaviour if no additional information is configured.

All it takes is:

import {SSE} from 'sse.js' 

EventSource = SSE;

I'd agree with you for another extension. But are you sure it's needed?

@Telroshan
Copy link
Collaborator

I liked the metaphor, though we'll be sticking to standards here!

After looking a bit more into it, you're right, I don't think it needs a separate extension.
If #132 makes it through with its new event, you'll be able to configure the request before the EventSource opens, and as you just have to replace the definition of EventSource globally to make htmx use the polyfill instead of the standard, there is probably no need to add anything else at the extension level to tackle this.
As it mimicks the syntax and as the whole options object would be passed to the SSE polyfill, it should do what you want here.

@XChikuX
Copy link
Author

XChikuX commented Jan 25, 2025

I liked the metaphor, though we'll be sticking to standards here!

I'm a standard's man myself. Just don't mind standard (+ additional feature if it makes sense.).

@Telroshan I'm confused. Do you think it should be a separate extension or this makes sense now?

PS: If you're implying I replace the EventSource globally for just my own usecase.

Could you give me an example of the whole options object. Would save me a tremendous amount of time going through the docs.

@Telroshan
Copy link
Collaborator

Sorry for the confusion @XChikuX !

To be clear, I think that:

Could you give me an example of the whole options object. Would save me a tremendous amount of time going through the docs.

This is not htmx related, it's simply the second parameter of the EventSource constructor, that the sse.js polyfill that you mentioned above, replicates exactly, adding extra properties to it along the way.
See their own documentation for the list of new options.
I hope you'll understand that I can't dive more into this nor give you more details about this options object itself, and kindly redirect you to their docs, as it's the library you mentioned & would like to use! The htmx SSE extension doesn't need to know about any of those anyway, just needs to pass the whole object, whatever it contains.

In terms of implementation for #132 , I imagine the SSE extension firing a CustomEvent, to let the user intercept it and modify the properties of a say event.detail.options object if they want, to pass any standard property or the new ones that sse.js defines, down to the EventSource constructor.

Hope this makes it clearer!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants