-
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
Ternary operator support #236
Comments
Hm I don't think we will implement this. Not a big demand for this at Shopify. Sorry. |
+1, Would be a big help for basic ternary operations
|
+1, I think this is needed. |
+1 must have,, gives the point of simplicity! |
+1 for this please |
This would definitely be a helpful feature. |
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. :/ |
@Rican7 yeah right? That's why I decided to never use liquid again :D |
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 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. |
@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? |
@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. |
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! 👍 |
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. |
@fredryk Basic example.. {% if product.available %}
<link itemprop="availability" href="http://schema.org/InStock" />
{% else %}
<link itemprop="availability" href="http://schema.org/OutOfStock" />
{% endif %} versus <link itemprop="availability"
href="http://schema.org/{{ product.available ? 'InStock' : 'OutofStock' }}" /> Just one off the top of my head. It's pretty much a code saver, but it'd be a great-to-have 😄 Or conditional classes, it's much more conventional to have <div class="{{ product.available ? 'available' : 'outofstock' }}"> .. </div> versus {% if product.available %}
<div class="available">
{% else %}
<div class="unavaialble">
{% endif %}
.. content ..
</div> |
@ajwhite, we could simplify things a bit more already:
Can be shortened down:
I like the use case though. Thanks for posting it! :) |
@fredryk Ah yes, can I embarrassingly remove that comment now? 😉 Good point though, that isn't too ugly, but also slightly less friendly as a ternary. Works though |
Here is the use case:
Filling in by finding the first available:
|
Here's another one:
|
I find Ternary operator construct unnecessarily hard to read in Liquid. To me anyway, Liquid is not a programming language, it is meant to be super simple. I am all for making Liquid do things that were not possible before, when these things are most needed, but since Liquid can do in a more verbose ( in my opinion easier to read ) way what a Ternary operator would allow, then this would make me give a 👎 . |
Correct, but when you can make assignments, it would be nice to have decent support in that. Nothing crazy, but something like a ternary makes an assignment based on a condition a lot easier to write.
I disagree, using @TWiStErRob's example, i think
reads pretty easily. It feels a lot easier to read than
I guess that comes down to personal preference. I, personally, don't think multi-lined assignments due to verbosity is easier to read. Being used to ternaries, it feels like extra work to understand the assignment by having to read multiple lines of conditional reassignments. |
I think this is key here, I could also argue for |
Hmm, lookey here, it's not ternary, but at least Elvis is alive! (added in #267) |
Nice, even an "Elvis operator" is a nice step up. Would still be nice to have a true ternary, but this is a good find |
@fredryk you can simplify it even more:
|
This is a good reason why Shopify hasn't become the clear leader in ecommerce. They think supporting developers is not in their best interest. Unfortunately, they don't realize the power of a strong recommendation from a developer to a potential customer. |
Yes, because they do not implement every single requested feature in an excellent library they make freely available to everyone, Shopify hates developers. Sure, ternary operator support would be great, but your claim is unreasonable and way out of proportion. And if I remember correctly, they do accept pull requests. |
I just re-read my comment and it did sound a bit harsh. :( That said, the only reason I know Liquid is because they require it to build their themes. I'm a customer myself, and I've developed themes for many of their customers, so don't think I'm using a free library and then complaining. In addition, this is just one of the many examples where it is clear that shopify ignores requests even with a need. This isn't helping them become a clear leader. I've been developing ecommerce sites for almost a decade and continue to have a high hope that someone will emerge as the leader. I really thought Shopify would, and it has a lot going for it, but I can see they're missing the opportunity to cater to developers and thus grow their market share. |
+1 |
+ထ |
Bruh, the ternary operators are literally some of the simplest things out there. And by making and developing Shopify themes, you'll have to eventually learn some Liquid template coding. You still have to learn for if/else statement for example: {% if product.available %}
<div class="available">
{% else %}
<div class="unavaialble">
{% endif %}
.. content ..
</div> and with the ternary operator you will end up only with: <div class="{{ product.available ? 'available' : 'outofstock' }}"> .. </div> which is much simpler and easier to read. By the way, it's 2023, still not added? |
I found this temp solution
and with the ternary operator you will end up only with:
By the way, it's 2023, still not added? |
10 years down the line and still not implemented. Why does Shopify provide such bad tools and support for developers? |
Another vote for this one |
+1 |
+1 Please |
+1 |
2 similar comments
+1 |
+1 |
+1 |
2 similar comments
+1 |
+1 |
Oh come on.. I got on this thread because I'd love a ternary operator and yes, 10 years after this has been open is a long time but...Shopify has really been great towards devs, especially in the past couple of years. I'd rather send them some love, maybe that's the way to get this topic sorted 😆 |
I must admit i am surprised this still hasnt been added. |
One century later.. |
Or... "one eternary later" 🤪. The most impressive comment is "Hm I don't think we will implement this. Not a big demand for this at Shopify. Sorry." (@fw42 ) |
That comment is over 10 years old. At the time it didn't seem like there was demand. Obviously I was wrong. Unfortunately I haven't worked for Shopify in over 4 years. |
@fw42 With your experience and approach, could you talk to the higher-ups, considering you're still in touch with them, and get them to notice this issue? |
Pleeeese add this feature! |
I am tired of writing I just want to do
|
…2522) To reproduce the bug: ```bibtex @inproceedings{Vaswani2017AttentionIA, title = {Attention is All you Need}, author = {Ashish Vaswani and Noam M. Shazeer and Niki Parmar and Jakob Uszkoreit and Llion Jones and Aidan N. Gomez and Lukasz Kaiser and Illia Polosukhin}, booktitle = {Neural Information Processing Systems}, year = {2017}, doi = {10.48550/arXiv.1706.03762}, altmetric = {21021191} } ``` The bug is 1. It seems to be some weird property of the liquid template that [line 252-254](https://github.com/alshedivat/al-folio/blob/8d82670ff170f98e7d7ea5434428234a8216d460/_layouts/bib.liquid#L252-L254) doesn't work at all. According to [this post](https://stackoverflow.com/questions/59887447/liquid-how-to-assign-the-output-of-an-operator-to-a-variable) and [this issue](Shopify/liquid#236), liquid doesn't support assign the output of operator to a variable nor a ternary operator. So based on my console log, the value of `entry_has_altmetric_badge` is always a string value of `entry.altmetric` when altmetric is provided in bibtex. ```liquid {% assign entry_has_altmetric_badge = entry.altmetric or entry.doi or entry.eprint or entry.pmid or entry.isbn %} {% assign entry_has_dimensions_badge = entry.dimensions or entry.doi or entry.pmid %} {% assign entry_has_google_scholar_badge = entry.google_scholar_id %} {% if entry_has_altmetric_badge or entry_has_dimensions_badge or entry_has_google_scholar_badge %} <div class="badges"> {% if site.enable_publication_badges.altmetric and entry_has_altmetric_badge %} <span ... ``` Note that this could be problematic that a string in liquid is always evaluated as true as long as it is defined regardless if it is "" or "false". [reference](https://shopify.github.io/liquid/basics/truthy-and-falsy/) 2. when altmetric is defined in bibtex, now the order of set attribute to badge is eprint > doi > altmetric id > pmid > ISBN, and the badge doesn't work when an arxiv doi is provided. I think the expected behavior should be 1. as documented in CUSTOMIZE.md, only render the badge when the entry is set to either "true" or the altmetric id. (It could also implement to always render the badge whenever doi or other related attribute is set, and set altmetric to "false" to disable it) ```md - `altmetric`: Adds an [Altmetric](https://www.altmetric.com/) badge (Note: if DOI is provided just use `true`, otherwise only add the altmetric identifier here - the link is generated automatically) ``` 2. if the almetric id is set, use it first.
…#2522) To reproduce the bug: ```bibtex @inproceedings{Vaswani2017AttentionIA, title = {Attention is All you Need}, author = {Ashish Vaswani and Noam M. Shazeer and Niki Parmar and Jakob Uszkoreit and Llion Jones and Aidan N. Gomez and Lukasz Kaiser and Illia Polosukhin}, booktitle = {Neural Information Processing Systems}, year = {2017}, doi = {10.48550/arXiv.1706.03762}, altmetric = {21021191} } ``` The bug is 1. It seems to be some weird property of the liquid template that [line 252-254](https://github.com/alshedivat/al-folio/blob/8d82670ff170f98e7d7ea5434428234a8216d460/_layouts/bib.liquid#L252-L254) doesn't work at all. According to [this post](https://stackoverflow.com/questions/59887447/liquid-how-to-assign-the-output-of-an-operator-to-a-variable) and [this issue](Shopify/liquid#236), liquid doesn't support assign the output of operator to a variable nor a ternary operator. So based on my console log, the value of `entry_has_altmetric_badge` is always a string value of `entry.altmetric` when altmetric is provided in bibtex. ```liquid {% assign entry_has_altmetric_badge = entry.altmetric or entry.doi or entry.eprint or entry.pmid or entry.isbn %} {% assign entry_has_dimensions_badge = entry.dimensions or entry.doi or entry.pmid %} {% assign entry_has_google_scholar_badge = entry.google_scholar_id %} {% if entry_has_altmetric_badge or entry_has_dimensions_badge or entry_has_google_scholar_badge %} <div class="badges"> {% if site.enable_publication_badges.altmetric and entry_has_altmetric_badge %} <span ... ``` Note that this could be problematic that a string in liquid is always evaluated as true as long as it is defined regardless if it is "" or "false". [reference](https://shopify.github.io/liquid/basics/truthy-and-falsy/) 2. when altmetric is defined in bibtex, now the order of set attribute to badge is eprint > doi > altmetric id > pmid > ISBN, and the badge doesn't work when an arxiv doi is provided. I think the expected behavior should be 1. as documented in CUSTOMIZE.md, only render the badge when the entry is set to either "true" or the altmetric id. (It could also implement to always render the badge whenever doi or other related attribute is set, and set altmetric to "false" to disable it) ```md - `altmetric`: Adds an [Altmetric](https://www.altmetric.com/) badge (Note: if DOI is provided just use `true`, otherwise only add the altmetric identifier here - the link is generated automatically) ``` 2. if the almetric id is set, use it first.
…lshedivat#2522) To reproduce the bug: ```bibtex @inproceedings{Vaswani2017AttentionIA, title = {Attention is All you Need}, author = {Ashish Vaswani and Noam M. Shazeer and Niki Parmar and Jakob Uszkoreit and Llion Jones and Aidan N. Gomez and Lukasz Kaiser and Illia Polosukhin}, booktitle = {Neural Information Processing Systems}, year = {2017}, doi = {10.48550/arXiv.1706.03762}, altmetric = {21021191} } ``` The bug is 1. It seems to be some weird property of the liquid template that [line 252-254](https://github.com/alshedivat/al-folio/blob/8d82670ff170f98e7d7ea5434428234a8216d460/_layouts/bib.liquid#L252-L254) doesn't work at all. According to [this post](https://stackoverflow.com/questions/59887447/liquid-how-to-assign-the-output-of-an-operator-to-a-variable) and [this issue](Shopify/liquid#236), liquid doesn't support assign the output of operator to a variable nor a ternary operator. So based on my console log, the value of `entry_has_altmetric_badge` is always a string value of `entry.altmetric` when altmetric is provided in bibtex. ```liquid {% assign entry_has_altmetric_badge = entry.altmetric or entry.doi or entry.eprint or entry.pmid or entry.isbn %} {% assign entry_has_dimensions_badge = entry.dimensions or entry.doi or entry.pmid %} {% assign entry_has_google_scholar_badge = entry.google_scholar_id %} {% if entry_has_altmetric_badge or entry_has_dimensions_badge or entry_has_google_scholar_badge %} <div class="badges"> {% if site.enable_publication_badges.altmetric and entry_has_altmetric_badge %} <span ... ``` Note that this could be problematic that a string in liquid is always evaluated as true as long as it is defined regardless if it is "" or "false". [reference](https://shopify.github.io/liquid/basics/truthy-and-falsy/) 2. when altmetric is defined in bibtex, now the order of set attribute to badge is eprint > doi > altmetric id > pmid > ISBN, and the badge doesn't work when an arxiv doi is provided. I think the expected behavior should be 1. as documented in CUSTOMIZE.md, only render the badge when the entry is set to either "true" or the altmetric id. (It could also implement to always render the badge whenever doi or other related attribute is set, and set altmetric to "false" to disable it) ```md - `altmetric`: Adds an [Altmetric](https://www.altmetric.com/) badge (Note: if DOI is provided just use `true`, otherwise only add the altmetric identifier here - the link is generated automatically) ``` 2. if the almetric id is set, use it first.
* Update README.md (alshedivat#2493) Added Physics-Morris.github.io to the list of academics. Co-authored-by: Morris Huang <morris8934@gamil.com> * Fixed issue with vega * Fix code blocks not changing to plots and others (alshedivat#2497) For some unknown reason, all the `document.onreadystatechange = () => {` checks stopped working. Thankfully, replacing them with `document.addEventListener("readystatechange", () => {` fixed the issues. --------- Signed-off-by: George Araujo <george.gcac@gmail.com> * fix: remove 'index.html' in pagination (alshedivat#2509) Currently, on the [blog](https://alshedivat.github.io/al-folio/blog/) page, clicking "older" and "newer" on the pagination at the bottom direct you forward to links like `/al-folio/blog/page/2/` and backward to `/al-folio/blog/`. However, if you click on the `1`, `2`.. etc buttons, there is a different behavior. The links now contain an `index.html`. For example, clicking `2` leads you to `/al-folio/blog/page/2/index.html`. It is the same content, just with a messier hyper link. Same with clicking `1`, you are brought to `/al-folio/blog/`. This fix creates a consistency among the hyper links in pagination. * Added SRaf.ir to README.md (alshedivat#2510) Hi, I would be more than happy if I could add my personal website here. * Support pirsch.io for analytics (alshedivat#2513) * Fixed external post symbol on search (alshedivat#2515) Fixes alshedivat#2471 Signed-off-by: George Araujo <george.gcac@gmail.com> * fix: blog highlighted in nav for child pages (alshedivat#2516) Currently, in all blog posts, or any child page under /blog, the "blog" in nav is not highlighted. In all other child pages for a parent in nav, the parent is highlighted. For example, in a sub page of projects, projects in nav is highlighted. This fix creates a consistent behavior for nav and highlights the blog in nav if in a blog post. BEFORE: <img width="1427" alt="image" src="https://github.com/alshedivat/al-folio/assets/52665298/fc79727c-dc22-4af7-8c16-80efa216ecbc"> AFTER: <img width="1434" alt="image" src="https://github.com/alshedivat/al-folio/assets/52665298/6b32e7f9-e421-4b08-b86e-813b20ac058e"> * Support superscripts in bibtex author names (alshedivat#2512) Implements alshedivat#2511 * Added support for a newsletter (alshedivat#2517) In reference to idea: alshedivat#2097 In reference to request: alshedivat#923 (comment) Added support to integrate a [loops.so](https://loops.so/) mailing list into the site. To use, you need to enable `newsletter` in `_config.yml`. You also must specify a loops endpoint (although I think any mailing list endpoint can work), which you can get when you set up a mailing list on loops. More documentation on loops: [here](https://loops.so/docs/forms/custom-form). Once that is enabled, the behavior is different depending on how you specified your footer to behave in `_config.yml`. If `footer_fixed: true`, then the sign up will appear at the bottom of the about page, as well as at the bottom of blog posts, if you enable `related_posts`. If `footer_fixed: false`, then the newsletter signup will be in the footer (on every page), like it is in on [my website](https://asboyer.com). I'm not attached to the placement of the signup, and you can choose to include it wherever you want with `{% include scripts/newsletter.liquid %}`. Also if you include positional variables into that, you can choose how you center the signup. So `{% include scripts/newsletter.liquid left=true %}` positions the signup bar to the left. Here are some screenshots below: ## Dark version ![image](https://github.com/alshedivat/al-folio/assets/52665298/af7fdb81-6e5f-47a9-958b-4cb93bba9e8f) ## Light version ![image](https://github.com/alshedivat/al-folio/assets/52665298/927f8bc5-b481-448b-ae5e-6f5b1c613243) I think the input field color should probably change to maybe be light for both themes? What do you think? I think the dark background looks cool, but I don't usually see that done like that on other sites. ## Footer fixed ![image](https://github.com/alshedivat/al-folio/assets/52665298/c52f3dc1-0e45-400e-8b71-eeb00d00cb01) ![image](https://github.com/alshedivat/al-folio/assets/52665298/678a2d45-88ab-4d9a-b8cc-9fc6db26d744) ## Footer not fixed ![image](https://github.com/alshedivat/al-folio/assets/52665298/fd2c0228-2bce-4335-ac3c-5cb20a3307e2) ![image](https://github.com/alshedivat/al-folio/assets/52665298/f594b4f2-67e0-4f2b-a3e8-febd579aaf19) To clarify, if footer isn't fixed, the email signup will appear on every page. --------- Co-authored-by: George <31376482+george-gca@users.noreply.github.com> * Fixed docker-slim.yml issue * Add example use of annotation and superscripts in bibtex (alshedivat#2520) ![image](https://github.com/alshedivat/al-folio/assets/33930674/e3018225-df99-4ebf-be18-5811f34fcf4b) ![image](https://github.com/alshedivat/al-folio/assets/33930674/afc6150e-0272-4180-bc5e-4ffbf5079239) ![image](https://github.com/alshedivat/al-folio/assets/33930674/40f88a17-4fba-4423-ab16-62fd37d7c574) ![image](https://github.com/alshedivat/al-folio/assets/33930674/c5cfe480-5df7-4f27-87c7-4883af1471ca) * Bib changes now trigger build action * Changes to docker-slim.yml now trigger action * Changes to deploy-image.yml now trigger action * Changes to deploy-docker-tag.yml now trigger action * Update CUSTOMIZE.md for Newsletter support (alshedivat#2521) In reference to alshedivat#2517 and alshedivat#2517 (comment) * Fix Altmetric badge not correctly set when Altmetric id is provided (alshedivat#2522) To reproduce the bug: ```bibtex @inproceedings{Vaswani2017AttentionIA, title = {Attention is All you Need}, author = {Ashish Vaswani and Noam M. Shazeer and Niki Parmar and Jakob Uszkoreit and Llion Jones and Aidan N. Gomez and Lukasz Kaiser and Illia Polosukhin}, booktitle = {Neural Information Processing Systems}, year = {2017}, doi = {10.48550/arXiv.1706.03762}, altmetric = {21021191} } ``` The bug is 1. It seems to be some weird property of the liquid template that [line 252-254](https://github.com/alshedivat/al-folio/blob/8d82670ff170f98e7d7ea5434428234a8216d460/_layouts/bib.liquid#L252-L254) doesn't work at all. According to [this post](https://stackoverflow.com/questions/59887447/liquid-how-to-assign-the-output-of-an-operator-to-a-variable) and [this issue](Shopify/liquid#236), liquid doesn't support assign the output of operator to a variable nor a ternary operator. So based on my console log, the value of `entry_has_altmetric_badge` is always a string value of `entry.altmetric` when altmetric is provided in bibtex. ```liquid {% assign entry_has_altmetric_badge = entry.altmetric or entry.doi or entry.eprint or entry.pmid or entry.isbn %} {% assign entry_has_dimensions_badge = entry.dimensions or entry.doi or entry.pmid %} {% assign entry_has_google_scholar_badge = entry.google_scholar_id %} {% if entry_has_altmetric_badge or entry_has_dimensions_badge or entry_has_google_scholar_badge %} <div class="badges"> {% if site.enable_publication_badges.altmetric and entry_has_altmetric_badge %} <span ... ``` Note that this could be problematic that a string in liquid is always evaluated as true as long as it is defined regardless if it is "" or "false". [reference](https://shopify.github.io/liquid/basics/truthy-and-falsy/) 2. when altmetric is defined in bibtex, now the order of set attribute to badge is eprint > doi > altmetric id > pmid > ISBN, and the badge doesn't work when an arxiv doi is provided. I think the expected behavior should be 1. as documented in CUSTOMIZE.md, only render the badge when the entry is set to either "true" or the altmetric id. (It could also implement to always render the badge whenever doi or other related attribute is set, and set altmetric to "false" to disable it) ```md - `altmetric`: Adds an [Altmetric](https://www.altmetric.com/) badge (Note: if DOI is provided just use `true`, otherwise only add the altmetric identifier here - the link is generated automatically) ``` 2. if the almetric id is set, use it first. * Fix repo card heigth for different repo descriptions (alshedivat#2525) Hello! I had this minor issue on my website and I saw few other people using this template and having the same issue. **Brief** if two repo's in the same row has different number of lines for the descriptions, heights of the cards will not be the same if we don't force the number of lines to be displayed. **Solution** By looking at [This issue](anuraghazra/github-readme-stats#2900) I could see that they solved it by adding an new option, `description_lines_count`. This was used on the API request in order to fix the issue. --- ## Issue reproduced: ![before](https://github.com/alshedivat/al-folio/assets/15076325/238931f5-8a0e-45c5-a9bb-e9c6e4c0f04b) --- ## Issue fixed after the commit: ![after](https://github.com/alshedivat/al-folio/assets/15076325/a0e79cdf-fd6a-4765-b21f-279540ae88fe) * Update README.md * Add linux x86-64 to Gemfile.lock (alshedivat#2549) Fixes alshedivat#2544 Generated via: ``` bundle lock --add-platform x86_64-linux ``` --------- Signed-off-by: George Araujo <george.gcac@gmail.com> Co-authored-by: Morris Huang <53600226+Physics-Morris@users.noreply.github.com> Co-authored-by: Morris Huang <morris8934@gamil.com> Co-authored-by: George <31376482+george-gca@users.noreply.github.com> Co-authored-by: Andrew Boyer <asboyer@gmail.com> Co-authored-by: saeedrafieyan <61290778+saeedrafieyan@users.noreply.github.com> Co-authored-by: ariseus <33930674+garywei944@users.noreply.github.com> Co-authored-by: Tiago Lobão <tiago.blobao@gmail.com> Co-authored-by: Maruan <alshedivat@users.noreply.github.com> Co-authored-by: Amir Pourmand <pourmand1376@gmail.com>
Hello!
I think it would be awesome to implement ternary operator support like Twig does:
The text was updated successfully, but these errors were encountered: