search

luckyframework / lucky

A full-featured Crystal web framework that catches bugs for you, runs incredibly fast, and helps you write code that lasts.
https://luckyframework.org
MIT License
2.59k stars 156 forks source link

Decouple HTML DSL from the framework #844

Open watzon opened 5 years ago

watzon commented 5 years ago

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.

matthewmcgarvey commented 3 years ago

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

stephendolan commented 3 years ago

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.

hovsater commented 3 years ago

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

jwoertink commented 3 years ago

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.

hovsater commented 3 years ago

@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. 🙂

jwoertink commented 3 years ago

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.

watzon commented 3 years ago

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.