lucky

lucky copied to clipboard

It would be nice if the HTML DSL were in it's own shard. This could be useful for a number of reasons, but the one I'm most concerned with is allowing the development of component libraries such as for Bootstrap or Bulma. Decoupling the DSL would make for easier testing, as you wouldn't have to install the full Lucky framework.

A nice first step to this would be to extract out the HTML DSL into a new module and separate the Lucky-specific tags/helper methods

I wonder if this could also help with introducing the HTML DSL into the Carbon library.

I've seen a number of issues in that repo that have been opened and closed regarding the topic, but never dug in too deeply.

I'd love to take a stab at this. 🙂

I know we've talked about doing this a few times, but there's also a few things we have to consider when doing it. One is, what makes ours different from https://github.com/crystal-lang/html_builder? I think the main answer is that we make ours a bit more type-safe with the Lucky::AllowedInTags, and the use of Wordsmith to handle converting attributes. But then the question becomes, does this new shard need knowledge of Lucky?

The next part is dealing with form helpers like https://github.com/luckyframework/lucky/blob/master/src/lucky/tags/form_helpers.cr. Does Lucky include a base HTML shard, and then extend past that for these helpers? Also note that we can't supply a link() html method because Lucky has a special link() method. So does this separate shard include link() -> <link />, and Lucky has to deal with ensuring that doesn't work?

I'm down for the abstraction, but I'd like to make sure we lock down the reason for the abstraction, as well as what we may gain / lose by going that route.

@jwoertink great points! I'd be up for discussing this further to ensure we're doing the right thing. I don't want to break it out for the sake of breaking it out. Only if it makes sense. 🙂

Sweet, let's chat about that. We can start the discussion on this thread just to keep it all in one spot. Maybe jot down what you're thinking in terms of porting that code over and such. I'll try to get a list together of where tricky spots might be.

Personally I am of the opinion that the external shard should keep as much of what makes it special as possible. Maybe extract Lucky::AllowedInTags as well. When it comes to anything Lucky specific though I'd say let Lucky extend the newly extracted shard and add the form builder and anything else that's needed.

To the last point about the link() method, I'd say the shard should include it and then Lucky can work around it. Shouldn't be too hard to override that method.