Ternary operator support

[Pym]

Hello!

I think it would be awesome to implement ternary operator support like Twig does:

{{ foo ? 'yes' : 'no' }}

{{ foo ?: 'no' }} == {{ foo ? foo : 'no' }}
{{ foo ? 'yes' }} == {{ foo ? 'yes' : '' }}

[fw42]

Hm I don't think we will implement this. Not a big demand for this at Shopify. Sorry.

[atticoos]

+1, Would be a big help for basic ternary operations

{{ foo ? 'yes' : 'no' }} please

[0xcaff]

+1, I think this is needed.

[mkdizajn]

+1 must have,, gives the point of simplicity!

[getdave]

+1 for this please

[Rican7]

This would definitely be a helpful feature.
+1 here

[Rican7]

PS: "Not a big demand for this at Shopify" isn't the best answer for why a feature shouldn't exist in an open source project. :/

[Pym]

@Rican7 yeah right? That's why I decided to never use liquid again :D

[nickpearson]

I don't work at Shopify and I don't speak for them, but I thought this was worth commenting on.

Liquid is a Shopify project that they were kind enough to open source. If a request comes in for a feature that won't benefit Shopify and its customers, it makes sense that Shopify wouldn't spend resources implementing it and (from their perspective) adding bloat to the project. However, the beautify of open source is that you can fork the project and implement whatever features you want.

For what it's worth, I agree with you that this would be a nice feature. Unfortunately it goes against Liquid's style of using just values, variables, and filters (and not expressions) for output, so I don't expect it to be implemented.

For some of my projects, I add a custom if filter. It basically works like a ternary expression, but it's written as a filter: {{ foo | if: 'yes', 'no' }}. The yes is outputted if foo is truthy, and no is outputted otherwise. The second (else) argument is optional. There's also an unless that's the opposite of if. Here's a super simple implementation:

module TernaryFilters
  def if(value, true_output, untrue_output = '')
    value ? true_output : untrue_output
  end

  def unless(value, untrue_output, true_output = '')
    value ? true_output : untrue_output
  end
end

Try it in an irb session:

# paste the module code from above

template = Liquid::Template.parse("{{ foo | if: 'yes', 'no' }}")
template.render({ 'foo' => true  }, filters: TernaryFilters) # => "yes"
template.render({ 'foo' => false }, filters: TernaryFilters) # => "no"

You of course may want to handle the value differently, such as treating a zero or an empty string as falsy. Hopefully this helps someone who wants a brief syntax for conditional output, Liquid-style.

[fw42]

@Rican7: Maybe we have different understandings of what open source software means. To me, it means that we will publish the code that we use ourselves (!) so that others can benefit from it (for free). We are totally cool with you forking this project and implementing whatever features you need for yourself. We are happy to consider any suggestions that you make, but the final decision of whether we will merge it into our version of Liquid is up to us. You have no right at all to demand features being included and I think "we don't need this feature at Shopify" is a totally legit reason to reject things. If you don't like it, don't use it.

Back to topic: I'm totally open to reconsider this decision. @Shopify/liquid, any more thoughts on the usefulness of this? @Shopify/design-gurus might have opinions too. Would this be helpful?

[atticoos]

@nickpearson makes a good point that Liquid folllows an approach of using just values, variables, and filters, rather than expressions, for output, however that can be a little constricting for many edge cases developers may encounter. Sure we can still achieve the desired output with a different set of variable assignments and conditions, but that, to us, is just a work around for not having an easy expression to call.

So without asking to review Liquid's approach to have a higher focus on expressions, it would be useful to introduce some basic/fundamental expressions that have low complexity and introduce an easier process of spitting out information, ternary support being one.

@fw42 Thanks for considering this as a possibility per discussion.

[Rican7]

I want to make it clear that I wasn't trying to insult anyone here. If I did, I apologize.

I was simply trying to say that its a very closed off approach to just deny a feature and close the issue without further conversation from the community. The decision absolutely comes down to the owner of the project, and pandering to every community request isn't an option either, but its discouraging to see such a terse response on a feature request that may prove valuable to the community.

Yes, the beauty of open source is that you're giving your code away for free, something that I believe anyone could appreciate. Its also under a very lenient license (MIT), so it could be modified and redistributed. However liquid has quite a large user base and usage pattern that isn't easily controlled by the user due to one fact: GitHub uses Jekyll, which uses Liquid templating, for both generating repo and user pages, so simply forking the project doesn't allow for the same workflow here.

Either way, I'm happy to see the reconsideration here. Thanks for listening! 👍

[fredryk]

In what we deal with day to day, I don't see a huge use for this… unless just to save a couple lines of code. I'd love to see a real world use case though.