Go module: Separate datastar core from implementation-specific dependencies.

[pdf]

Currently the datastar module in this repo pulls in a whole raft of dependencies (e.g. templ, gostar, go-chi, nats, etc) including all the stuff required for the example apps - 66 deps in total as of this writing.

For projects that wouldn't otherwise rely on any of these dependencies, that's a lot of code pulled in just to get access to the datastar-specific helpers for constructing SSE events.

Moving example applications to their own modules would help significantly, but I'd also suggest moving any template-/component-library specific code out of the main lib, and into their own separate modules so that users that choose other solutions don't have to pull in those dependency trees. Alternatively, if the SEEEvent type implemented io.Writer for appending to data, it could work with pretty much any template language, which is how I've been rendering components into SSE events using HTMX.

I don't see much good reason for depending on anything outside the stdlib in main module TBH - functions like BodySanitize(), BodyUnmarshal() and QueryStringUnmarshal() are probably better left to documentation, as they're all both trivial and need not necessarily be implemented using the libraries chosen here.

EDIT: As an aside, I probably would've liked to have seen the SSE implementation separated from event generation - if SSEEvents were self-contained (and could e.g. Render(io.writer)) that would make them much more flexible, allowing them to be passed around more easily before being sent down the wire, rather than necessarily being constructed in the same scope as the SSEServer is available.

[delaneyj]

I mostly agree with you. There are some people that are going to contribute helpers for other languages. I think we'll be moving them into a subfolder anyways and it could have it's own go.mod. I will say that the deps for gostar/templ/chi are less of a concern that's to tree shaking.

[pdf]

It's true that a lot of the deps get shaken out, but templ/gostar etc end up included because of their render methods in the main module.

[delaneyj]

right, I :heart: templ and I made gostar, i'm ok with these deps for rendering. still will get tree shook at the final binary level depending of what you use. But moving to it's own dir in helpers/go/datastar/datastar.go makes a lot of sense