Move the HTML-specific code into a Lucky::HTML module

[matthewmcgarvey]

Right now html code is mixed throughout the codebase. There's Lucky::BaseComponent and Lucky::HTMLPage and several modules in the lucky/page_helpers directory but not in a Lucky::PageHelpers module.

I think it would be best to make a module called Lucky::HTML and lucky/html directory and move everything html related into it.

What do you think?

[stuckerab]

That's cool. That's actually a feature I was just evaluating. It's the 'V' of the MVC I was looking for! Ha!

I was hoping to make something that works just like the /views directory in Rails does.

/lucky/views/layouts to house the general over-arching layout file for things like headers, footers, etc. exactly like Rails does now.
/lucky/views/namespace-or-route-path/view_file.cr
/lucky/views/components to house commonly styled/themed page components that are used within the actual page templates.

I've had this idea/pattern for my rails apps for the past 3 years and it's been working beautifully.

So, think of Tailwind CSS and their idea of having predefined CSS utilities that control small aspects of the styling and can be combined as classes onto HTML pieces. Well why not have that as part of the pattern for displaying HTML?

For example, let's say my sites theme has 3 types of buttons that could be used. I'd want to declare the styling with a placeholder that accepts. I'll use boostrap classes here because it's super well-known off the cusp.

<button class="btn btn-primary btn-lg my-2 mx-3" additional_attributes() >#{button_text}</button>
<button class="btn btn-secondary btn-lg my-2 mx-3" additional_attributes()>#{button_text}</button>
<button class="btn btn-danger btn-lg my-2 mx-3" additional_attributes() >#{button_text}</button>

In my mind, I would like to be able to call those buttons like a method, pass in parameters with the first being the tags contents and accepting a (forgive my ruby class reference here) Hash of keys/values and turning them into additional attributes on the tag.

I'm clearly still very new to Crystal, but I'm super excited to get using this language on my projects and I think with the "utility first" approach that is emerging from the front-end world right now, it's something that could be adopted into Lucky and you'd be able to attract a lot more of the "utility first" crowd of full-stack developers.

Hopefully that's pretty clear and easy to understand. And hopefully I understand what you were trying to describe.

[matthewmcgarvey]

Hey @stuckerab, thanks for getting involved in the discussions and checking out Lucky!

This was more for code internal to Lucky, to get it better organized and easier to discover.

As for your thoughts, in the Lucky world we write HTML as crystal code so we get a whole bunch of re-usability and abstractions for free! Want to have a similar button with only text differences? Extract a method! Need to configure theming as well? Try extracting a Lucky component!

If you want to look more into how Lucky view layer code is written, and the abstractions specifically, here's a link to where we talk about it in the docs: https://luckyframework.org/guides/frontend/rendering-html#extracting-methods-for-code-clarity

Hope to hear from you more, and join us in the discord if you haven't already!

[rmarronnier]

Excellent idea !

I'm wondering (not convinced yet) if it's worth it to make Lucky::HTML its own shard in its own repo so that it could be used outside of Lucky. The drawback is that https://github.com/luckyframework has already so many children... :p

Also, could this move make easier to use external templates system for those allergic to Lucky HTML DSL ?

[rmarronnier]

Great finds @jwoertink .

When I started working with Crystal, the Lucky way of building views with a HTML DSL was offputting so I went with Amber for my first toy project.
Later on, I decided to experiment with Lucky despite the DSL and surprinsingly grew fond of it. I could see myself using it outside of Lucky (with Kemal for example). By a cursory glance Lucky HTML is more complete and powerful than https://github.com/crystal-lang/html_builder

The more I think about it, I can't see why we shouldn't have a Lucky HTML shard.

We already have very specific shards like https://github.com/luckyframework/wordsmith for example

We don't really want to encourage the possibilities of using other templating engines for your views.

The best way to "encourage" going the full Lucky way is with the Lucky CLI generating views which use the HTML DSL.

I'd rather not split out lucky::html into it's own shard.

What would we lose ? :-)

[jwoertink]

building views with a HTML DSL was offputting

It was the same for me, and actually most people. It's a bit jarring when you first see it. I think it's not until you use it when you finally "get it". That's why for new people coming to Lucky, we need to promote the conversion tool https://luckyframework.org/html to help them see it's easy to move over!

Originally I wanted to break it out because I wanted to use it for Carbon emails. But then after writing several cross-platform compliant emails, I realized that it's so bad (the emails) that we couldn't make that happen with the Lucky HTML. Probably fine if you don't get too fancy 🤔

I just took a look at it, and realized that it would be a bit more difficult than I thought originally. Think about this; The link helpers couldn't be abstracted out because those require knowledge of Lucky::Action. That wouldn't exist in Kemal. The csrf helpers couldn't be abstracted because even though they need knowledge of context which Kemal does have, they also need to know about ProtectFromForgery.get_token(@context) which calls to context.session (a Lucky::Session object). Since those can't be moved out, that also means form_for can't be moved out because those inject the csrf inputs (as well as knowledge of Lucky::Action).

So really, unless we made Lucky itself a dependency, we'd only be abstracting out 3/4 of the library leaving the last bit still in place. That means we end up segmenting the overall HTML. Someone new comes along, and say "oh, where's the code for this bit? I can't find it in the Lucky::HTML shard" only to find out it's actually in Lucky, or vice versa.

[robacarp]

Code discoverability and maintainability is the primary reason I don't want lucky broken out into (more) shards as well. It increases friction for people who want to contribute and use lucky. Projects like dry-rb are really neat for how composable they are, but when you hit a wall and want to read the source for the framework you end up spending an hour just finding the code you want to diagnose.

[jwoertink]

maintainability

yup.... Especially since it's mainly just myself and @matthewmcgarvey doing most of the heavy lifting on the framework. This update for Crystal 1.0 alone has me about burnt out. I've had to push PRs for about 17 shards within Lucky, plus another 4 or 5 outside that Lucky depends on. 😪

I'm hoping that Crystal will support multiple shards in the same repo some day. That might allow us to break them out, but still keep them in the same repo for easier maintainability. It would also help reduce the friction of the circular dependencies which would be amazing 🙌 But that's probably a Crystal 2.0 level feature 😒

[rmarronnier]

So really, unless we made Lucky itself a dependency, we'd only be abstracting out 3/4 of the library leaving the last bit still in place. That means we end up segmenting the overall HTML.

That's what I feared.

yup.... Especially since it's mainly just myself and @matthewmcgarvey doing most of the heavy lifting on the framework. This update for Crystal 1.0 alone has me about burnt out.

For what it's worth, I'm sorry to hear that. I hope you get back to the enjoyable stuff soon enough