Add typings

Resources

Actually, I've already put some work into creating a TypeScript definition file so I could get intellisence, code completion, refactoring, etc. in IDE's that understand t.ds (TypeScript definition files). But that was for a much earlier version 0.0.8. A lot has changed. 🎢 A TypeScript declaration file is for use with JavaScript. As the user types, he/she gets information about a method's call signature, expected parameters, and the parameter's types. It will also show basically whatever documentation you provide for that in the IDE. It's a very helpful feature when you're not familiar with an API. Once I know an API, I dispense with it. Here's a video about intellisense
That said, it doesn't make sense to deal with typings until you have a fairly stable API. That's why I stopped working on my t.ds. Things were changing to quickly so 🏖
By the way, I've written a number of TypeScript definition files and contributed to definitelytyped.org. I've got about 80,000 lines of TypeScript under my belt. But I'm currently just doing ES6.

@rbiggs

Thanks for the clarification @rbiggs! 👍

I've got about 80,000 lines of TypeScript under my belt.

Awesome! Please help me create the typings when the API has stabilized. Let's keep this issue open until then.

No probs. I'd probably just make a fork for that. Hardest part doing the original one was discerning the return types in a few places. Geez, seems that always the hardest part of creating a typings file 🤔

We'd want to also put together a typings test to run against actual code. You have to use every feature so that the TypeScript compiler and test types in all possible situations. It doesn't usually take that much code to pull that off.

Just let me know when you feel you have your feature set stable. One thing, the plumbing can change quite a bit without affecting the public type interface, as long as call signatures and return types remain the same. Something to be aware of when you decide when you want to introduce types.

@rbiggs

@rbiggs I will, thanks! I'll probably create a typings branch, push some stuff there and asked you to take a look. 👍

It would be really cool if my IDE/Editor could autocomplete app's props as one types. I think that's one of the cool merits that come with adding typings.

Give me a ping out whether you're looking to convert or just add .d.ts files. We're planning on making a few utilities available for easily testing type declarations.

@DanielRosenwasser

Hi @DanielRosenwasser, not convert, but add a .d.ts file. Similar to https://github.com/developit/mitt/blob/master/mitt.d.ts perhaps.

Is there any ongoing work on this? I have a TypeScript project and I'm considering using hyperapp for the UI due to its similarity to the Elm Architecture.

@LucianU

@LucianU Now that 0.8.0 is out, it might be a good time to start working on it. I am not familiar with the process so any help is welcome.

@rbiggs

@jbucaran, I haven't written any typings either, but I'm considering learning it. Maybe @rbiggs can help, since he said he has experience with the process.

Naive declaration file based on the API doc. On a gist to facilitate discussion about it

https://gist.github.com/Swizz/964c027075168b1ad8a66fd4fee6a0cc

@Swizz

@Swizz Can you open a PR with this?

@Swizz

@Swizz, I just tried the following and it seems to have good results:

interface ActionsObject<State> {
    [prop: string]: ((state: State) => State) | ActionsObject<State>
}

interface VNode {
    tag: string;
    data: any;
    children: HyperStateChild;
}

type HyperStateChild = string | VNode | HyperStateChildrenArray;
interface HyperStateChildrenArray extends Array<HyperStateChild> { }

interface Options<State, Actions> {
    state?: State;
    view?: (state: State, actions: Actions) => VNode;
    actions?: Actions;
}

declare function h(tag: string, data?: any, ...children: HyperStateChild[]): VNode;
declare function app<State, Actions extends ActionsObject<State>,>(obj: Options<State, Actions>): void;


app({
    state: {
        us: "no strangers to love",
        you: "know the rules and so do I"
    },
    actions: {
        foo: {
            bar: s => s
        }
    },
    view: (s, a) => h("div")
});

However, there seems to be a problem with this when both noImplicitAny and strictNullChecks are used together, so I filed this issue. A workaround is just to tell users to turn off one, or make actions non-optional.

I want to advise on this matter. If you're willing to put .d.ts files into your repo, you should feel confident that you know how to work with and support these files, and that you're willing to roll out a patch release if something is incorrect with them. The same goes with something like .js.flow files as well, or anything similar.

If you're not comfortable with that, the best course of action is probably to send the .d.ts files to DefinitelyTyped and have an active hand in the quality/accuracy of them, possibly. There are a bunch of other benefits to using DefinitelyTyped too. For example, we can test all type declarations that depend on each other if they reside in DefinitelyTyped to understand potential breakages.

The alternative solution is to author in TypeScript and worry less about synchronizing the .d.ts and .js files.

I aimed to be as close as possible to the API documentation, because guys made all the job here.

I know I am against the TS styleguide with lowercase type/interface but first I wanted to translate the API documentation.
But your one inspire me a lot of things to make the declaration even simplier.

The major issue is Hyperapp is still in active development and its API could change at any time. Maintain a DefinitelyTyped declaration will be a mess. It could be more easy to have a kind a test who check declaration file against breaking changes. And an active TS dev to fix it in any PR.

I'm against writing code in TypeScript. It would force certain checks which would increase bundle size (or a bunch of casting which will just make the code ugly and lose the purpose of TypeScript).

The library is super-small and with proper documentation (which we have), I don't think we need a transpiler step. A lot of code is already optimized by hand.

I guess .d.ts files could be tested by writing a "fake consumer" test in TypeScript, which would fail compile-time if the API changed and definitions are not updated?

@Swizz

@Swizz The existing APIs will definitely not change at this point. Some stuff may get deleted (or added), but things like the function signature (state, actions, data, emit) is certain not to change.

EDIT: Having said that, I don't think stuff will get added, other than components, assuming those happen (I hope).

Just updated the gist with more Generics 🎉
https://gist.github.com/Swizz/964c027075168b1ad8a66fd4fee6a0cc

import { h, app, Actions, Application } from 'hyperapp'

interface State {
  readonly count?: number,
  readonly name?: string
}

interface ActionsInterface extends Actions<State> {
  inc(state: State): State,

  subspace: {
    dec(state: State): State
  }
}

const application: Application<State, ActionsInterface, undefined> = {
  state: {
    count: 0,
    name: "Jojo"
  },

  actions: {
    inc: state => ({ count: (state.count || 0) + 1 }),

    subspace: {
      dec: state => ({ count: (state.count || 0) - 1 })
    }
  },

  view: (state: State, actions: ActionsInterface) => h('div', undefined, [
    h('h1', undefined, (state.name || '')),
    h('h2', undefined, (state.count || 0)),
    h('div', undefined, [
      h('button', { onclick: actions.inc}, '+'),
      h('button', { onclick: actions.subspace.dec }, '-')
    ])
  ])
}

app(application)

// or

app<State, ActionsInterface, undefined>({
  state: ... ,
  actions: ... ,
  view: ...
})

Works well with noImplicitAny and strictNullChecks.

If there is no objections, I will start to work on a PR 👍

two things to note:

actions may not return a State but a subset of it (which is then merged with the state). If I am not wrong, a subset of an object in TypeScript can be modeled using Pick<T>.
Events: it can contain custom events, not just loaded, render etc... So I think it should be modeled as a map.

If anyone can open a PR we could continue the discussion there and close here. 👋🤔

@nippur72

Yeap, I was waiting, some PR to be closed, Regarding #266 #259

I will make a PR within day. After documenting on @nippur72 suggestions.

we also need to redefine the JSX namespace in order to enable the jsx syntax (aka .tsx). I tried the react one but event handlers don't match with HyperApp actions. But I guess we can predate and adapt @types\react.

I am on it, with JSX support (in naive way, btw) 😄

https://github.com/Swizz/hyperapp/blob/typing/hyperapp.d.ts

I am ready to PR after few more tests ; but no solutions about Events yet.

edit :

interface IntrinsicElements {
  [elemName: string]: VNodeData;
}

is not correct, the correct one is

interface IntrinsicElements extends VNodeData { }

edit2 :
No, it is not, I was correct on the first try 👍

Closing in favor of #279.

Navigation Menu

Repository navigation

Add typings #87

Resources

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add typings #87

Description

Resources

Activity

rbiggs commented on Feb 14, 2017

jorgebucaran commented on Feb 14, 2017

rbiggs commented on Feb 14, 2017

rbiggs commented on Feb 14, 2017

rbiggs commented on Feb 14, 2017

jorgebucaran commented on Feb 14, 2017

jorgebucaran commented on Feb 27, 2017

DanielRosenwasser commented on Mar 21, 2017

jorgebucaran commented on Mar 21, 2017

LucianU commented on Apr 13, 2017

jorgebucaran commented on Apr 13, 2017

LucianU commented on Apr 14, 2017

Swizz commented on Jun 28, 2017

jorgebucaran commented on Jun 29, 2017

1 remaining item

DanielRosenwasser commented on Jun 29, 2017

DanielRosenwasser commented on Jun 29, 2017

Swizz commented on Jun 29, 2017

lazarljubenovic commented on Jun 29, 2017

jorgebucaran commented on Jun 29, 2017

Swizz commented on Jun 29, 2017

Swizz commented on Jun 29, 2017

nippur72 commented on Jul 3, 2017

jorgebucaran commented on Jul 4, 2017

Swizz commented on Jul 4, 2017

nippur72 commented on Jul 4, 2017

Swizz commented on Jul 4, 2017

jorgebucaran commented on Jul 16, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions