-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Centralizing to_liquid #1532
base: main
Are you sure you want to change the base?
Centralizing to_liquid #1532
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -582,8 +582,7 @@ def empty? | |
|
||
def each | ||
@input.each do |e| | ||
e.context = @context if e.respond_to?(:context=) | ||
yield(e.respond_to?(:to_liquid) ? e.to_liquid : e) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This removal is core to the goal I am trying to reach. While this one filter is in the main codebase, any filters built by the gem users currently need to be aware of build around this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This I think at the moment filters should be able to depend on the immediate value being passed in being a liquid value. They just need to use to_liquid conversions for nested values. Even if that weren't the case, we would still have similar concerns in drops, so I don't really see a good way of providing a non-leaking abstraction around this concern at the moment. |
||
yield(e) | ||
end | ||
end | ||
end | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -417,6 +417,8 @@ def test_map_doesnt_call_arbitrary_stuff | |
assert_template_result("", '{{ "foo" | map: "inspect" }}') | ||
end | ||
|
||
# This test succeed in the ruby implementation, but not in liquid-c | ||
# See Context#contextualize | ||
def test_map_calls_to_liquid | ||
t = TestThing.new | ||
assert_template_result("woot: 1", '{{ foo | map: "whatever" }}', "foo" => [t]) | ||
|
@@ -433,6 +435,8 @@ def test_legacy_map_on_hashes_with_dynamic_key | |
assert_template_result("42", template, "thing" => hash) | ||
end | ||
|
||
# This test succeed in the ruby implementation, but not in liquid-c | ||
# See Context#contextualize | ||
def test_sort_calls_to_liquid | ||
t = TestThing.new | ||
Liquid::Template.parse('{{ foo | sort: "whatever" }}').render("foo" => [t]) | ||
|
@@ -861,7 +865,7 @@ def test_all_filters_never_raise_non_liquid_exception | |
{ foo: "bar" }, | ||
[{ "foo" => "bar" }, { "foo" => 123 }, { "foo" => nil }, { "foo" => true }, { "foo" => ["foo", "bar"] }], | ||
{ 1 => "bar" }, | ||
["foo", 123, nil, true, false, Drop, ["foo"], { foo: "bar" }], | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think passing a Before the current changes, you will see a Only the StandardFilters apply that |
||
["foo", 123, nil, true, false, test_drop, test_enum, ["foo"], { foo: "bar" }], | ||
] | ||
StandardFilters.public_instance_methods(false).each do |method| | ||
arg_count = @filters.method(method).arity | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a non-trivial conversion to be doing on variable access, especially since there wouldn't be anything to make sure it isn't done redundantly. E.g. if an array of hashes were iterated, then this deep conversion would be done when accessing the array along with the inner hashes, then each hash would be converted again when they are accessed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also completely remove the advantage of
Proc
lazy evaluation.I'm not sure how much lazy said evaluation is needed when it comes to non-root elements, but it is an impactful mechanism.