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

Adding Logical Operators to Templates #562

Open
wants to merge 4 commits into
base: master
from

Conversation

@cibernox
Copy link
Contributor

cibernox commented Dec 8, 2019

Extracted from RFC #388

Rendered


## Unresolved questions

- Consider following Javascript's definition of truthiness. This would also help with the transition from `ember-truth-helpers`.

This comment has been minimized.

Copy link
@chriskrycho

chriskrycho Dec 9, 2019

Contributor

Probably belongs under “Alternatives” instead.

This comment has been minimized.

Copy link
@cibernox

cibernox Dec 9, 2019

Author Contributor

I'd argue that it belongs here. The way I understand RFCs, alternatives is where you list alternative options to implementing the RFC, not so much about doubts regarding what the best implementation is.

If anyone can confirm that I got it wrong, I'm happy to change it.

This comment has been minimized.

Copy link
@Gaurav0

Gaurav0 Dec 10, 2019

Contributor

I think an exact implementation of ember-truth-helpers logical operators (except maybe not) is not what anyone wants, given the desire for short circuit logic. But alternatives sections are not always fully specced out, so I think with just a little more detail, you could write an alternative.

This comment has been minimized.

Copy link
@webark

webark Dec 10, 2019

Being someone who believes that the lack of logical operators is the main benefit that handlebars provides, and one who has never had a need to install this addon in the many ember apps i have built, simply assuming that this is something that is required to be installed does not sit well with me. I would like somewhere in this process to highlight the benefits that not having these be a part of the framework provides.

This comment has been minimized.

Copy link
@cibernox

cibernox Dec 10, 2019

Author Contributor

@webark You can certainly live without those helpers, but I'll add some examples of things that are much nicer with helpers like those:

Default Values in template-only components

Imagine a template only component that wants to have a default value for say, @name

<img class="avatar" src={{or @user.avatar "/imgs/default-avatar.png">

Perform an operation on each iteration of a loop without extracting another component

{{#each @users as |user|}}
  Name: {{user.name}} 
  {{#if (and session.hasAdminPrivileges user.inactive)}}
    <button {{on "click" this.activate}}>Delete</button>
  {{/if}}
{{/each}}

In both situation you can find a way to do the same things without using any of those helpers, but it involve either create a JS file for a component only to put a computed property on it, or to extract a new component to call it on each iteration of a loop, just to perform a very simple logical operation.

It's a matter of convenience and as any tool it can be abused, but the popularity of ember-truth-helpers proves that devs really find it convenient.

I think that Ember providing just the most basic and used ones (and, or, not, eq are the main 4 for me, but this RFC focuses on the first 3) and optimized at the VM level we are alleviating a pain.

This comment has been minimized.

Copy link
@webark

webark Dec 11, 2019

call me a curmudgeon (and i’ll postpone my “at this point we might as well be using jsx” rant for another day) I just feel it should be mentioned why this was never in core to begin with. Your examples, to me, are the base examples of why. Just a brief “handlebars was originally meant to be “logic-less” but it has grown, and the community has pushed it, past that for sometime now” blurb would be helpful, at least for a historical sense.

cibernox and others added 2 commits Dec 9, 2019
Co-Authored-By: Chris Krycho <hello@chriskrycho.com>
@Gaurav0

This comment has been minimized.

Copy link
Contributor

Gaurav0 commented Dec 10, 2019

Being someone who believes that the lack of logical operators is the main benefit that handlebars provides, and one who has never had a need to install this addon in the many ember apps i have built, simply assuming that this is something that is required to be installed does not sit well with me. I would like somewhere in this process to highlight the benefits that not having these be a part of the framework provides.

I think this needs more discussion in the other helpers, but for these particular helpers, we can't build short circuit versions without direct core support. Would it be possible to build some primitives to make short circuiting possible while keeping the helpers (and actual semantics) in an addon?

@cibernox

This comment has been minimized.

Copy link
Contributor Author

cibernox commented Dec 10, 2019

I think this needs more discussion in the other helpers, but for these particular helpers, we can't build short circuit versions without direct core support. Would it be possible to build some primitives to make short circuiting possible while keeping the helpers (and actual semantics) in an addon?

@Gaurav0 I'll add it as a note, but even if it was possible and short-circuiting was possible in user-land, I still think those helpers are useful regardless of any optimization we may add, so I don't want to focus the RFC on the possible performance improvements.

Probably on the big picture the perf improvements we may squeeze from short-circuiting will be rather small in anything but pretty contrived examples.

Copy link
Member

Turbo87 left a comment

yes, please! 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.