DEV Community

Discussion on: The EmberJS of the future... today!

 
nullvoxpopuli profile image
NullVoxPopuli • Edited

Javascript/Typescript are extremely dynamic and expressive languages. Why do you think you need them?

How else would you denote something via shorthand as 'tracked' / cached so that it only updates when it needs to?

Why do you like this? How is this better than a directive that injects and listens to changes of the prop? Vue has v-model="variable" that can be put onto any component. How is a handlebar helper that is tied to a form input better? How is this not just considered bloat to you?

It's actually a shorthand, so, in Ember, you can totally just do:

<input value={{this.something}} oninput={{action this.updateSomething}} />

where then in your JS, you'd need:

updateSomething(e)  {
  const value = e.target.value;

  this.set('something', value);
  // note that set is going away in the future as ember moves away from it's pre-es6 object model (soon)
  // set is used as a bit of a trigger to update all the cached / dependent computed properties once before a re-render. 
  // once set is removed, this'll be wrapped behavior from the `@tracked` decorator
  // NOTE: for any React readers, this is like this.setState, but with super powers :)
}

So, that is equiv to:

{{input value=something onChange=(action (mut something))}}

so, no js involved. It's just a personal preference, imo. There are plenty of ember people who opt for as much of the native DOM behavior as possible.

side question: what all does v-model="variable do in Vue? it doesn't seem specific to anything and seems somewhat generic? Above, I use value= because an input expects a value.

Not having the templates be javascript is fine. The issue I was talking about is I can't use that {{t helper in a javascript method of mine. I'm sure Ember has an alternative for accessing the i18n strings in JS but that was a great opportunity that they missed out on.

Most helpers, like t, have two exports. 1. A default export (used by templates), and 2. A named export of a pure function that actually does the behavior. The named export is what can get imported into the js.
For t, specifically, it's exposed in additional ways as a service, so you can bind changes in your app to a change in locale but also as a direct import

You really can. My prefered way if you want a singleton service export default new MyService()

Personally, I think this is an accident of how bundlers evaluate scripts at build time.

DI is a pattern, it's fine to use it, I have too, but there are better ways.

to each their own. most things have purposes.

On a second viewing it's not bad, I'm just not used to it. Polymer did a lot of this too, but I'd just listen to the keys. I don't know how the full ember event system works but in Vue

So, my keyboard usage here is an API that I came up with (linked, is the template-less component that is in the screenshot) using lower-level keyboard event handling. I also didn't want my key events tied to a specific component (though, that is certainly an option, the lib I'm using is very flexible ).

I personally am not a fan of dynamically interpreted keys (even though there isn't a real good way around it when it comes to defining the shortcuts)), but I'd write your example (with my existing KeyboardPress component)

<KeyboardPress @key="alt+s" @onKeyDown={{action this.toggleModelVisibility}} />

I'd imagine though, if you wanted similar behavior from Vue, you could get close. You'd likely have to eval that string "modelVisible = !modelVisible", so.. that could be risky.