Proposal: Gomponents LSP

[cachesdev]

Currently, the implementation of gomponents give you type safe attribute and tag names, but we have no type safety on attribute values themselves.

Implementing an LSP (or cli utility) shouldn't be too complicated, as most of the work has already been done: the html lsp already exists, and templ has already done something similar.

In theory, all this program needs to do is convert gomponents syntax back to HTML, give this a pass with the html lsp, then return back the wrapped messages in a way that would be compatible with gomponents syntax.

I think it's worth discussing, I haven't made a POC due to lack of time (yet), but the tools and similar implementation are all there to look at and learn from.

[markuswustenberg]

That sounds cool! I have absolutely no experience with something like this though, and not enough time at the moment to investigate something like this. If you end up experimenting with it, please share! 😊

[amrojjeh]

Wouldn't it be easier (though still time consuming) to just convert the attribute functions so they accept non-string types such as constants, bools, or numbers? It adds much more weight to maintenance and I personally rarely mess up the values, so I don't find it worth it, but if it's really desired, then I imagine this would be the least technically difficult way to do it

[markuswustenberg]

Wouldn't it be easier (though still time consuming) to just convert the attribute functions so they accept non-string types such as constants, bools, or numbers? It adds much more weight to maintenance and I personally rarely mess up the values, so I don't find it worth it, but if it's really desired, then I imagine this would be the least technically difficult way to do it

Hmm, good point. I think I've thought about this before, but can't remember my reasoning.

One problem I can think of from the top of my head is, if attribute values are ever augmented with new values that don't fit within the current type, it could potentially be a breaking change to change the type later.

I'll think about it some more. 😊

[amrojjeh]

It doesn't have to be. You could do something like this:

type DirValue string

const (
    DIR_RTL = DirValue("rtl"),
    DIR_LTR = DirValue("ltr"),
    DIR_AUTO = DirValue("auto"),
)

func Dir(DirValue value) g.Node {
    return g.Attr("dir", string(value))
}

This pattern is simple and easy to update, and in the worst case, the end user would just have to pass their own DirValue. As I said, I personally don't think it's worth it since it's rare for me to mess these up, but if I were to implement it, this is how I'd do it (and it can probably be automated with a code generator)

[markuswustenberg]

Hmm, true. And you could probably make it in a way that doesn't break backwards compatibility.

I agree, it's not worth it right now (at least I don't see a compelling reason). Thanks for your input!

[markuswustenberg]

I've started a language server repo here: https://github.com/maragudk/gomponents-language-server

I'll spend a few hours looking into what it takes to create a language server like this.

[mvdve]

The nice thing about gocomponents is that it is pure functions. When an LSP is introduced, there is an other dependency with it's own issues. Let's keep it simple i would say.

[markuswustenberg]

The nice thing about gocomponents is that it is pure functions. When an LSP is introduced, there is an other dependency with it's own issues. Let's keep it simple i would say.

Don't worry, I appreciate the simplicity and elegance as much as you do. Something like this would only be an optional add-on for those who want it, never a requirement to use the library. :-)