Skip to content
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

false values turn into nil #122

Open
kanwei opened this issue May 19, 2016 · 6 comments
Open

false values turn into nil #122

kanwei opened this issue May 19, 2016 · 6 comments
Labels

Comments

@kanwei
Copy link

kanwei commented May 19, 2016

Passing in something as a boolean false seems to turn into a nil. So:

(println (render "Blah {{boo|str}}" {:boo false}))

prints "Blah" instead of "Blah false" as expected when doing (str false) in regular clojure.

@yogthos
Copy link
Owner

yogthos commented May 19, 2016

That's because lookup in the context map that results in a false is treated as absence of value, so it never gets to the filter. Changing this would affect the existing API however, so I'd be hesitant to do that. A workaround would be to stringify false values before passing them to render.

@brunchboy
Copy link
Contributor

Whoops, it looks like this tripped us up in our API documentation generator, which relies on some nested Selmer templates and custom tags, as well. I think your suggested workaround may work for us, though, because I am tracking separately whether the value being rendered is supposed to be a string literal or not.

@pimeys
Copy link

pimeys commented Jan 10, 2017

Is this going to be fixed at some point? We just found the bug on production and were kind of surprised how it works. (str value) of course helps for now.

@yogthos
Copy link
Owner

yogthos commented Jan 10, 2017

My only hesitation here is that it would be a breaking API change for the library. Perhaps one approach would be to make this a configuration option.

@mlococo
Copy link

mlococo commented Jan 16, 2018

Personally, I'd rev the major version at some point and fix this. I get that breaking changes are a big deal, but I have trouble believing that anyone wants this behavior. It seems like leaving a landmine for new users in perpetuity is the greater evil compared to a breaking change properly labelled in a major release.

This bit me in a real-world project and caused, what was from my perspective, a rendering bug in the resulting application that was present for several releases before being found by internal testing and only then did we find this bug report.

@yogthos
Copy link
Owner

yogthos commented Jan 17, 2018

It sounds like the consensus here is that it would be a desirable change. I'm open to a PR for this. The breaking change could be noted in the change log. I think that would be adequate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants