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

About the new alias syntax {{#each items item, @index index}} #3225

Closed
giovannipiller opened this issue Apr 6, 2018 · 6 comments
Closed

Comments

@giovannipiller
Copy link
Contributor

Hi there!
Not sure if this has been already discussed, but I was peeking through the 0.10 Changelog and noticed this new feature:

The as in aliases is now optional so {{#each items as item, @Index as index}} is equivalent to {{#each items item, @Index index}}.


I'm not sure if it's worth introducing another syntax just to remove the as keyword.
Wouldn't this complicate the readability/maintenance of the template code or Ractive's internal?

I feel like this is kinda like the "implicit" {{# something}} .... {{/}} syntax, which might look appealing, but complicates things on the long run.

Having an additional syntax means:

  • more documentation
  • more code
  • more issues 😄

What do you think?

@dagnelies
Copy link
Contributor

+10 ...I think too removing the as makes it more confusing/unclear!

@evs-chris
Copy link
Contributor

I don't disagree. When originally proposing the feature, I got a good bit of pushback based on the verbosity of it, which is fair. This is somewhat of a compromise on that front. For context, the value as alias syntax is borrowed from SQL, where the as is also optional.

I think leaving out the optional keywords has a place. For instance, when playing with the feature during development, I found that I prefer to drop them. I also like to drop them where they don't add necessary padding with larger alias blocks e.g. {{#with @index idx, @keypath path, foo - 12 as count, .bar.baz bip}}.

As far as maintainability of the Ractive internals, this part of the change only affected one or two lines, and if I remember correctly, is actually less code now because it doesn't have to reset the parser position and bail if it doesn't match.

If there is pretty universal hatred for dropped as, it is marked experimental and can be removed (re-added?) pretty easily. That's why I went ahead and pushed out 0.10 with experimental features - people seem to be more willing to try them out when they're not limited to edge releases so I get more feedback. So... thanks for raising this issue!

@giovannipiller
Copy link
Contributor Author

Thanks for the replies,
I'll expand a bit more, then if others want to chime in, they're more than welcome 😊

I have no problem from my perspective, since I'll be using as pretty much everywhere, but I can see it being very confusing to newcomers.

{{#each}} and {{#with}} already have a lot of "special" features going on (ex. defining a context, various @ keywords, the "older" array:index syntax, "implicit" syntax, the new shuffle thing...), I'm afraid that adding further complexity might be too much.

as seems like a simple enough keyword, which carries a lot of meaning by itself, and kinda reminds of import { foo as bar } from 'module' 😎


That's why I went ahead and pushed out 0.10 with experimental features - people seem to be more willing to try them out when they're not limited to edge releases so I get more feedback.

Agreed, that was a very good idea!

@giovannipiller
Copy link
Contributor Author

If nobody else has strong feelings about this, feel free to close the issue.

I've been using as for years now, and it's great and straightforward! I still think that dropping it creates more confusion than not, but as long as it remains optional it's no big deal.

@evs-chris
Copy link
Contributor

My strongest feeling is that a lot of stuff is a bit overloaded syntactically and can get confusing. I think we got a little outside the capabilities of handlebars. I've been looking at how best to some that for 2.0 without also making migration a pain. It's tough, and I don't really have a solution so far other than possibly supporting two flavors of template that parse down to the same ast.

@ceremcem
Copy link

ceremcem commented Apr 4, 2020

I want to specify my point of view to increase the contrast for the below claim:

I have no problem from my perspective, since I'll be using as pretty much everywhere, but I can see it being very confusing to newcomers.

It also introduces a lot more confusion for me (oldcomers) while reading someone else's code who prefers omitting the as keyword.

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

No branches or pull requests

5 participants