luckyframework / luckyframework/lucky
Add native ECR support
Nobody has claimed this yet.
- Dominant language
- Crystal
- Stars
- 2.7k
- Forks
- 172
- PR merge metrics
- No merged PRs in 30d
Description
We have docs on setting up Kilt and using ECR embedded in your page https://luckyframework.org/guides/frontend/rendering-html#rendering-html-with-templates-ecr-slang-etc
But this setup is a bit complicated since it relies on you setting up a full Lucky::Page then embedding your ECR within it.
You can also use ECR directly from your action, but it's not as straight forward, and not documented:
class Posts::Index < BrowserAction
get "/posts" do
posts = PostQuery.new
send_text_response ECR.render("src/pages/posts.ecr"), content_type: html_content_type, status: 200
end
end
We should just make a method like
# assume these are always in `./src/pages/`
# Also default assume content_type is HTML, but allow for an override
render_ecr "posts/index.ecr"
def render_ecr(page_path : String, content_type : String = html_content_type, status : Int32? = nil) : Lucky::TextResponse
send_text_response ECR.render(Path["#{Dir.current}/src/pages/#{page_path}"]),
content_type: content_type,
status: status
end
Only wonky thing I'm not a fan of is that variables have to be defined in this weird floating area. You'd have to tell Ameba to ignore these because they'd be used in the template. But this would be fairly close to how Kemal works https://kemalcr.com/guide/#views-templates
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with BrowserAction and compare the documented Kilt/Lucky::Page rendering path with the direct ECR.render example in the issue. Determine how native ECR rendering should handle the src/pages/ path, content type, status, and template variables; done means the proposed action-level usage is supported and documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- crystal
- Domain
- backend, web-dev
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100