Activity

1. Telroshan

   transferred this issue frombigskysoftware/htmxon Jan 25, 2025
2. Telroshan

   added

   enhancementNew feature or requestNew feature or request

   on Jan 25, 2025
3. Telroshan commented on Jan 25, 2025

   

   Telroshan

   on Jan 25, 2025

   Collaborator

   More actions

   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
4. Telroshan

   added

   new extension

   and removed

   enhancementNew feature or requestNew feature or request

   on Jan 25, 2025
5. XChikuX commented on Jan 25, 2025

   

   XChikuX

   on Jan 25, 2025

   Author

   More actions

   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?
6. Telroshan commented on Jan 25, 2025

   

   Telroshan

   on Jan 25, 2025

   Collaborator

   More actions

   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.
7. XChikuX commented on Jan 25, 2025

   

   XChikuX

   on Jan 25, 2025

   Last edited by XChikuX

   Author

   More actions

   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.
8. Telroshan commented on Jan 26, 2025

   

   Telroshan

   on Jan 26, 2025

   Collaborator

   More actions

   Sorry for the confusion @XChikuX !

   To be clear, I think that:

   • We don't need a separate extension as sse.js can gracefully replace the browser's EventSource definition without breaking anything. So if you want to use this SSE implementation instead of the browser's one, you just have to include their script before the htmx SSE extension, which will make the latter use the SSE polyfill instead of the browser's EventSource, without any additional work on the htmx side (see the first section of their README)
   • SSE extension: Add the ability to send data to the endpoint before the connecction is being made similar to htmx:configRequest or htmx:wsConfigSend #132 with the new event it'll introduce, will let you intercept the event source setup and define any additional property that sse.js supports, as it mimics the syntax of the EventSource constructor docs

   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!