Hacker News Reader

Comment by notjustanymike | Hacker News Reader

I saw that, it leaves out a lot. In production you'll need something that formats the response and handles errors, which means defining a custom Event Source. It seems like the functionality quickly returns to traditional javascript when any normal amount of complexity is required.

View on HN

As one of the other replies mentioned, the fetch will throw an event that you listen for. The server is the response formatter. The piece of the puzzle that you're missing is that the intent is that this library is used with the author's other library, htmx[0]. With htmx, the expectation is that you're always returning HTML as the response (though there are extensions available so you can return JSON that could be processed against a client-side handlebars template).

[0] https://htmx.org

Apparently when the fetch fails, it triggers an `fetch:error` event[1], which can (probably) be handled somewhere. No idea about formatting the response, though.

I think it's quite natural for there to be large gaps in functionality provided: it looks like a rather young and unpopular project, so the additional code needed to handle more situations from within the language still needs to get written. jQuery also didn't have a whole universe of plugins from day 1, but was useful enough anyway. Not saying this project has a chance to become another jquery, just that it too can be useful even in a far-from-complete state.

[1] https://github.com/bigskysoftware/_hyperscript/blob/master/s...

Yep, you can have an `on fetch:error` clause in the element's script.

Wrt. formatting the response, I'm experimenting with a hyperscript template language [1]. However, we don't yet have a design for imperatively building DOM trees (other than just doing it the same way you would in JS).

[1]: https://dev.hyperscript.org/commands/render/

Reply on news.ycombinator.com