Conversation
|
I've starting looking over this one, but there is quite a bit going on, so it's a little difficult to wrap my head around what all is happening. It seems like maybe this is changing how actions are handled? I'd really like to avoid that from changing and just keep this about defining what method doing the serialization for the serializers i.e. JSON serializers use to_json, XML serializers use to_xml or whatever, etc... I appreciate the PR and stoked to start adding some new stuff! I'll try to finish up an actual review soon! 🙌 |
|
I keep thinking about this... I wonder if we can actually make it a lot more simple.... I was looking at this recent PR on Crystal https://github.com/crystal-lang/crystal/pull/15939/files and it got me thinking... What if your serialization was just based on a simple require? require "lucky/serializable/json"
abstract struct BaseSerializer
include Lucky::Serializable
endThen that would just have module Lucky::Serializable
def to_json(io)
render.to_json
end
endThen if you wanted your own custom serialization method, you would just open module Lucky::Serializable
def to_yaml(io)
render.to_yaml
end
end
class Data::Index < BrowserAction
get "/data" do
serializer = DataSerializer.new(1, 2, 3)
if yaml?
yaml(serializer)
elsif json?
json(serializer)
else
plain_text(serializer.render.to_s)
end
end
endLucky already has the built-in methods used for handling the action output. Serializers just need to know how to convert your |
|
I agree with you :
makes so much sense. What I liked about this PR was especially the |
Purpose
This is a working POC as an alternative solution to #1948 (it's not a configuration per se).
I've added several format as examples and let the md files as documentation (they can be removed, content extracted etc) to show clearly what this would look like.
I find the syntax neat and simple enough. What do you think ?
Checklist
crystal tool format spec src./script/setup./script/test