Modularize LuckyHtml

[rmarronnier]

Following #1441 this is a POC that we can extract html capabilities into its own module. Benefits in the short term might be to have API lucky apps not requiring this code. Maybe be its own shard down the line.

[jwoertink]

This is a good concept. With this just being a PoC, I don't think we could merge as-is, but I do like the benefit of API apps could just not require any of it for maybe a (very very tiny) compilation boost? Though, I was under the impression that Crystal (and LLVM) will just optimize all that code not being used out anyway. Do you happen to have any benchmarks as far as binary size, or compilation differences between a basic "hello world" app for API and Browser based apps?

As an aside, one thing we have to keep in mind is that Avram requires the HTML currently https://github.com/luckyframework/avram/tree/main/src/lucky/ext so it can add extensions for forms using Operations. So if we did abstract this out in to a separate shard, we'd just need to make sure it was still accessible to Avram for this case. I'd assume this extra shard would probably just stay a dependency of Lucky itself, right?

[rmarronnier]

Thanks for getting back this fast to me.

As an aside, one thing we have to keep in mind is that Avram requires the HTML currently https://github.com/luckyframework/avram/tree/main/src/lucky/ext so it can add extensions for forms using Operations. So if we did abstract this out in to a separate shard, we'd just need to make sure it was still accessible to Avram for this case. I'd assume this extra shard would probably just stay a dependency of Lucky itself, right?

This is the main issue and design faux pas. An ORM shouldn't have hard requirements on front end rendering features. This should get adressed first. This seems like a no brainer to me, but maybe you're not convinced ?

[jwoertink]

An ORM shouldn't have hard requirements on front end

True; however, it either Lucky requires the ORM always, or the ORM always requires the front-end 😂 We don't really have any options here unless we completely remove the type-safety we get on the front-end forms. Originally Avram was tightly coupled with Lucky which meant that you couldn't have a Lucky app without requiring that postgres and Avram were added in. This included the Lucky website itself which doesn't need any database. By removing Avram from Lucky and reversing the dependencies, people can now add in their own custom ORM or none at all with Lucky. This just means that Avram is stuck with that responsibility.

I guess we could turn that in to a separate 3rd shard itself too... It would just make doing integration testing a lot more difficult with the LuckyCLI 😬

[rmarronnier]

I don't know if it pushes the conversation forward :
I don't mind having Avram or Operation specific html macro outside of Lucky HTML (maybe in the Avram shard), like form_for. We'll keep a simple (and dumb) form html macro. Same thing for the html form inputs : right now text_input and co depend on Avram. But why can't we have a simple and dumb input html macro ?