Add constants for common attribute values

[jjba23]

In order to write cleaner code when working with gomponents, a suggestion I have is that we create some exported constants that can be used for everyone using this project. This avoids typos, repetition and ensures a consistent usage of attribute values. I would suggest creating a new file in gomponents/html/attributevalues.go where we can add exported constants. Of course it might make more sense to expose these constants in a different package. Also, take these constant names with a pinch of salt, we should strive to have some obvious and consistent naming.

What do you think of this idea @markuswustenberg ? I think is really worth doing.

For example (pseudocode):

Source(
    Type("image/webp"),
)
Form(
    AutoComplete("off"),
)
Input(
    Type("text"),
)
Input(
    Type("email"),
)

could be turned into:

Source(
    Type(ImageWEBP),
)
Form(
    AutoComplete(Off),
)
Input(
    Type(InputTypeText),
)
Input(
    Type(InputTypeEmail),
)

[jjba23]

I would be happy to do some research and gather as many attribute values as possible and make a PR with them, but of course I would like some opinion on if you think this is worth it.

[markuswustenberg]

@averageflow thank you for the idea. I've actually tried something similar, but ended up deleting most of it again (for example, InputHidden for an input element with type hidden and a value given as a parameter, which is actually still there in the components package I see now). In practice, I never used the helpers, because the pain of writing out Input(Type("hidden"), Value("")) isn't large enough, I guess. With bigger components, it's a different story entirely.

I think it's also really hard to decide which components should be included and which not. With all the combinations, the API surface area could really quickly explode, and I think that would be confusing for most users.

As you might have guessed, I lean towards not including something like this in the gomponents core library. Maybe it would be worth it for you to create a small library on your own that uses gomponents, and get some real world testing of the idea, and then we can have a review round and see how it works out? I'd be happy to include it on the website at https://www.gomponents.com/mentions/

Thoughts?

[jjba23]

@markuswustenberg I fully understand your reasoning. I will start on it when I have some time left and make it a sort of useful extension to gomponents. The separation of concerns is definitely something good 👍🏼 I will keep you posted

[markuswustenberg]

@averageflow nice, sounds good. 😊 I'll keep this issue open for updates.

[jjba23]

Began working on this https://github.com/averageflow/htmlgonstants. I expect it will take some time to get a more finished and useful project.

[markuswustenberg]

Began working on this https://github.com/averageflow/htmlgonstants. I expect it will take some time to get a more finished and useful project.

Cool! Love the name. :D I'll follow it and see where it's heading.

[markuswustenberg]

@averageflow how's your experience with the constants? Does it make creating views easier for you?

I've thought about it a bit since. I really like the idea that it guards against typos in strings, but I'm a bit worried about increasing the API surface area by a lot, because there are so many possible values. Do you have any thoughts about that?

[jjba23]

@markuswustenberg thanks for bringing this up! I have been quite busy, my company's 2 last quarters of the year are always very busy so I have been occupied with other tasks and projects, more in the backend. I have plans to move all frontend applications that currently use html/template into gomponents, and then the htmlgonstants will really come in handy.

I have moved already 2 applications, and 1 of them currently is using htmlgonstants.

The benefits are immediately visible, and of course you are safer against typos, and my fellow more inexperienced developers can also learn more about what HTML API has to offer thanks to the IDE autocomplete features.

I fully agree that it might be too much to add this to gomponents, and it might be better to have it in a separate package. As you might see I still have not tagged the project since I feel I have not covered as much as I would like, but for what I use, it already satisfies my needs. I would love to see contributions to it and people using it, since it is a small but helpful addition.

I will keep you posted when I am going more in-depth into using gomponents.

[markuswustenberg]

@averageflow thanks for the quick reply! No worries, of course you have other stuff to do as well. 😊

That sounds cool. I'm looking forward to learning more about your experience with both gomponents and htmlgonstants, if you'd like to share at some point.

Personally, I'm pretty happy with using gomponents in my projects as well, but there sure are a lot of strings involved. I think I'll give htmlgonstants a try as well.