You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately, this is a bit of an edge case because the current behavior is designed to allow @ symbol to be specified in a default literal. What happens specifically is this:
(defnlookup-args"Given a context map, return a function that accepts a filter argument and if it begins with @, return the value from the context map instead of treating it as a literal."
[context-map]
(fn [^String arg]
(if (and (> (count arg) 1) (.startsWith arg "@"))
(let [accessor (parse-accessor (subs arg 1))]
(get-in context-map accessor arg))
arg)))
The lookup-args function tries to find the path in the context @props.notes, and since the path doesn't exist it assumes the argument was a literal.
Reproduction:
In the templates I’m writing, I had expected the filter to return either nil or a blank string.
@yogthos I’m not sure if we should consider this a bug or a feature request, but either way, what do you think?
The text was updated successfully, but these errors were encountered: