Add typescript signatures for Alt

[Shearerbeard]

Finished the basics tonight working as much off the docs as possible, should have a finished TodoMVC example tomorrow - I would be more than happy to throw the code in a public repo or whatever you think helps the most.

[goatslacker]

A PR in this repo is ok. Anywhere is fine really. I'll take a patch through any medium.

[omencat]

Cant wait!

[Shearerbeard]

I have a full TodoMVC example working off my definitions in a local branch that I'll try and get uploaded tonight. You can check out my current typings in the dist directory of my fork. I may need a second set of eyes as extending a store with a few static methods (like the areAllComplete method in the todomvc example ) and getting it to compile is a bit verbose. Also there are a few awkward points as Alt expects its StoreModel and ActionsClass to call methods that are not implemented until after the alt.createStore and alt.generateActions methods. This causes compile errors unless I extend an "Abstract" class that needs containing those method references. Example:

interface State {
  todos?:{[key:string]:Todo}
}

//Dummy Class To help TodoStore compile - Messy!
class StoreModel {
    bindActions( ...actions:Array<Object>):void {};
    getState():State {
      return <State>{};
    };
}

class TodoStore extends StoreModel implements AltJS.StoreModel<State> {
   todos:State;

  constructor() {
    // requires extension of Store model to compile with these methods
    this.bindActions(todoActions)
    this.todos = {};
    super();
  }
  //implementation details
}

//separate function as static methods in typescript will not compile with a reference to *this*
function areAllComplete() {
  var { todos } = this.getState();
    for (var id in todos) {
      if (!todos[id].complete) {
        return false
      }
    }
    return true
}

//State model passed via generic
let todoStore = alt.createStore<State>(TodoStore);

//must reassign to a new Type in order to not throw a compile error when adding areAllComplete
interface ExtendedAltStore extends AltJS.AltStore<State> {
  areAllComplete?():boolean;
}

//Reassigning generated store to a new interface to avoid compile errors on extension
let extendedTodoStore:ExtendedAltStore = todoStore;

//Hinting and typing works perfect for our store methods!!
extendedTodoStore.areAllComplete = areAllComplete.bind(todoStore);

I think ideally we would have an exported base class for StoreModel and ActionsClass to extend off of but any suggestions that may be better than this would be appreciated.

[omencat]

Thanks for the work so far. I like the idea of exporting the store and action classes. React seems to be moving this direction as well with React.createClass, can now use plain ES6 classes.

export class Locations extends React.Component<Props, {}> {
    constructor(props: Props) {
        super(props);
    }
    ...
}

This would be much cleaner in typescript and avoid the need to implement dummy classes to get around the compiler errors.

[Shearerbeard]

Yes, the new React classes and type definitions have been a heavy inspiration on this work - passing state and props as interface generics has made the library a type safe pleasure to work with. Is anyone familiar enough with the decorators in alt to know if this might be a cleaner translation to typescript? I couldnt find documentation other than the @connecToStores in the readme.

[Shearerbeard]

todo mvc example is up. I'll probably submit a PR for the initial typings here in a bit. As my typescript app based on alt and react continues to grow me and my team will update more of the API and try to share any findings as we progress. As of right now the typings only cover the base alt import included in the documentation at http://alt.js.org, I have yet to dive into any of the optional imports. Did we want to eventually move my demo over to the examples directory?

[Shearerbeard]

Type definitions now support all main features - I've ported another example with the updated definitions here. I was originally thinking that the d.ts file should be part of the npm/bower package and simply installed with the tsd link command but I'm having a really hard time getting the dependent typings to resolve at compile time. Perhaps the best course of action is to do a PR to get these up on the TSD repo so they can automatically pull in their dependencies (eventemitter3, react, flux) from the package manager to avoid duplicates in your project.

[Shearerbeard]

PR submitting - after its accepted ill submit a PR with tsd to get this included in the definition manager.

[goatslacker]

Thanks for this!