Typescript and Vue in general

[indus]

I have a small problem; I'm in love with two things at the same time: Typescript and Vue.
I tried a handfull different approaches to make them work together; using TS modules and/or classes with public/private/static properties to shim vue components is the best i got.
I love the intelisense, autocompletion and error hints i get by doing so!
But after all it is kind of hacky.

I wanted to ask you what you think about Typescript? Do you think it is possible to bring them togeher in a more natural way?
Maybe refactoring some parts of your extend routine (to make some of its internals reachable from a typescript construtor) could make a huge difference.

[yyx990803]

Personally I haven't used TypeScript much; Vue requires some pretty special treatment in how its extend functionality works, so I need to look into how TS' class transpiling works first.

On the other hand I know @diverted247 is working with Vue in TS a lot and he has https://github.com/diverted247/vuets which works with 0.10.6. You might want to take a look at that and join forces?

[indus]

I made a gist with my pattern: https://gist.github.com/indus/0c1ff6b4f4102a6286a8
and maybe it helps somebody else, too.
after all I think there is little you can do to bring Vues "extend" and TSs "extend" closer together.

[diverted247]

Indus, the issue in extending Vue directly in TypeScript is the call to super. Vue implied (pre1.6) that configuration is passed in the constructor yet this proceeds TS class member creation. The fix was to add support to Vue to pass false to the constructor and defer configuration to a call to Vue.init( config ). The change allows you to then map a TypeScript class into Vue with no side effects. We are using it in production and are seeing very few limitations. Key logic is here https://github.com/diverted247/vuets/blob/master/todomvc/js/app.ts

[yyx990803]

In 0.11 the Vue.extend logic has been greatly simplified (the option merging is externalized from the constructor, all constructors simply call this._init): https://github.com/yyx990803/vue/blob/0.11.0-rc3/src/api/global.js#L27-L45

I think this should make TS integration a bit easier than 0.10. What do you guys think?

[indus]

I missed that change in V0.11
Thanks you

[indus]

diverted247, how can i merge options in your code? Lets say I create something that needs a "ready"-funktion in its internal setup, but you also want to give a user the possibility to paste in their own options as well, with another 'ready'-function for example (constructor(instanceOpt?)).
Maybe 'mergeOptions()' from the Vues extend-procedure should be available in Vue.util? But where should it be called? On every instantiation seems wrong.

[diverted247]

TypeScript just needs a way to:

1. Subclass Vue via prototype
2. Pass configuration to instance not via constructor.

TypeScript class instances create members after the call to super and thus
creates a subtle timing issue. Vue could only be instanciated by passing a
configuration via constructor so subclasses would fail when attempting to
pass members to super before they existed. <insert chicken & egg joke>
Solution was to pass super(false) to Vue, then call a separate Vue method
to set the configuration via the subclass.

I am 100% ok with the team breaking VueTS to make Vue better. I can adapt
if there is an external way to set configuration in Vue.

Ted :)

On Mon, Oct 27, 2014 at 4:01 AM, indus notifications@github.com wrote:

diverted247, how can i merge options in your code? Lets say I create
something that needs a "ready"-funktion in its internal setup, but you also
want to give a user the possibility to paste in their own options as well,
with another 'ready'-function for example (constructor(instanceOpt?)).
Maybe 'mergeOptions()' from the Vues extend-procedure should be available
in Vue.util? But where should it be called? On every instantiation seems
wrong.

—
Reply to this email directly or view it on GitHub
https://github.com/yyx990803/vue/issues/478#issuecomment-60564516.

[indus]

I made a gist for the pattern i use (with a basic definition file):
https://gist.github.com/indus/0c1ff6b4f4102a6286a8

I use this in all of my vue-projects and it works perfect for me, even subclassing (this got even better with TS 1.3 and the protected modifier).
But although I have to say that this is not the "holy grale" and the only truth.

diverted247 made a nice comparisson (https://github.com/diverted247/vuets) of the two possible aproches. To sum it up from my perspective:

1. use a module: straight forward, almost no benifits over plain JS
2. misuse a class: a small hack, get benifits from TS like intellisense

I think the second approach (done like shown in my gist) is way superior, because writing the definition files is always a weak point in using TS. Only few have the passion to write them, and keeping them up-to-date is constant work. With the class-approch you get your definitions while you are writing you code and it stays in sync to your development.

But as I said, until TS or Vue make a significant move towards the other, it all depends on your paradigm: "no hacks" or "no affort"

I think making Vue fit to TS wont be painless and affects parts in your code I don´t fully oversee, but would maybe also be worth the trouble.

[temp-name-9956]

Hi,

does anything changed with Vue 0.12.x introduction? We have a business need to use TypeScript. Application it self have to be made of set of small to medium size independent, decoupled components, so Vue looks like a natural choice here. But lack of TS support is a big blocker for us.

RivetsJS looks like abandoned, so that's not an option neither, however it's way to bind any JS object with any jQuery node object is nice and in fact it solves the problem. Is it possible in Vue to implement (in reasonable time amount) such behavior? I mean implementing it in some real and vue-native way, not by embedding custom object inside VueComponent object, or anything like that, which will most likely cause some problems down the road anyway.

If not, are there any other options? As far as i can tell, by quick looking at Vue's code, the .extend() concept goes quite deep. Can't see an easy solution for that.

As to the above solutions from @indus and @diverted247 - not sure i understood it correctly, byt - i must say that we're on a beginning of a big app rewrite and the feelings are strong to avoid hacking and unusual use of libraries, so really - we're not happy to hack Vue extend concept this way.

Anyway @indus and @diverted247, did you manage to solve this some other/better way?

And @yyx990803 how do you think if it's possible/reasonable to alter Vue's extend mechanism? And how hard eventually it would be?

[yyx990803]

@sl-codenine now that I think about it, it would be possible to simulate Vue.extend using annotations (similar to how Angular 2 does it):

@component({
  // Vue.extend() options here...
})
class MyComponent extends Vue {}

Or, declare the options as a static property and simply add a decorator:

@component
class MyComponent extends Vue {
  static options = {
    // options here...
  }
}

Maybe even make it look more "classy" if we do a bit more plumbing in the decorator (not sure if feasible):

@component
class MyComponent extends Vue {
  // data
  msg = 'hello!'
  // method
  greet() {
    console.log(this.msg)
  }
  // computed
  get computedMsg() {
    return 'computed ' + this.msg
  }
  // lifecycle hooks (reserved method names)
  ready() {
    this.greet()
  }
  // assets
  static directives = { /* ... */ }
  static filters = { /* ... */ }
  // other options
  static options = {
    // other options here...
  }
}

In the end a Vue subclass is defined as:

1. Prototypally inheriting Vue;
2. Having a static options object that contains the component options. There's a "merge" step which is what happens in Vue.extend, but we can do that in the decorator by extracting the options from the class declaration (it seems we can only do that for static properties?)

And obviously, this requires using TypeScript 1.5+

[diverted247]

One issue with VueTS is that you end up fighting the internal nature of Vue. Vue has an elegant api in use of JS objects but cramming that into TS via Classes or TS Language features may not be the best choice.

I have been using Vue 11/12 with TS by simply typing the values directly and not using class/modules. I would love to see deeper integration with TypeScript but something is lost in the process. Unless it is done from the ground up similar to Angular2 approach.

One key issue is the misalignment of model definitions and model instance use within Vue. This makes the TS compiler go stir crasy as model properties are created in one place, yet used at runtime somewhere else. This mapping is hard to wrap with a TypeScript definition as the properties are app specific not something Vue has knowledge of. Take this example...

var demo = new Vue({
    el: '#demo',
    data: {
        message: 'Hello Vue.js!'
    }
})

demo.message = "Hello Vue.ts!";

TypeScript can see .el and .data but .message is part of the app model definition. The problem comes when demo.message is set as TypeScript does not know where this came from and thus it is clearly an error( compiler perspective). The VueTS solution was to have a class extend Vue and define properties as class members thus the instance API is in sync with the class definition. It was sort of favoring the vue instance API and generating the Vue constructor api to suit. Works but not ideal.

I am pretty sure there is a great solution here. I would love to see TS and Vue work closer together and would be happy to help. I have 3 projects using Vue+TS and would love to have a better solution.

Ted :)

[muten84]

Have you thinked about GWT +Vue? I have a small project on my github repos test uses Vue and Gwt and generate application skeleton at compile time. If TS is not a requirement it would be a nice solution for Java developers.

[yyx990803]

@muten84 I've never used GWT, so I honestly have no idea what is needed to make it work with Vue :/