I can remove the extra parentheses, it was for readability purpose but prettier do it as well

Let's give prettier the last word! :)

It was not :/
Cause union types :
(a: number, b: string) => number | string
A function that take a as a number and b as a string and return a number or a string

is not
((a: number, b: string) => number) | string
A function that take a as a number and b as a string and return a number. Or a string

So let's let them here.

@Swizz So prettier is wrong?

I was right by writing them; prettier was right to keep them ; I was wrong at reading them again to take them as extra parentheses

omg 😆

So, following #280 (comment)

An action could return either a Partial<State>, any or void or never ?

@Swizz An action can return an entire state (the same or a new one), a fragment of the state, a Promise, null or undefined.

A Promise that resolve to a State (or fragment) ?

=> Partial<State> | Promise<Partial<State>> | void | never

A Promise that resolves to any.

Something more like ?

=> Partial<State> | Promise<Partial<State> | any> | void | never

Is void === undefined?

void is the opposite of any both undefined or null.
But with strictNullChecks enable, it is needed to define null explicitly.

in TypeScript void works a bit differently than other languages (C, Java etc); it's not just "no return value", but it's more like an alias for undefined. For example:

function a(): void {}
let b = a(); // strange, but this is allowed, and it's b === undefined

So I think it's ok to have void and left out undefined from our signature. I would also omit any because it makes the signature useless for type checking.

So we are back on a circular type reference ?

type ActionResult = Partial<State> | Promise<ActionResult> | void | null

export interface Actions<State> {
    [key: string]:
      | ((
          state?: State,
          actions?: Actions<State>,
          data?: any,
          emit?: emitFunction<any>
        ) => ActionResult)
      | Actions<State>
  }

I think it should be Partial<State> | Promise<Partial<State>> | void

We are on discussion about it above ^^'

@Swizz Why not declare namespace hyperapp {?

Both are similar but different. declaring module are more ES6/CommonJS where declaring namespace is more like exposing a global object.
This is why if you export and object you will need to export the namespace too.

export = HyperApp

declare namespace HyperApp {
  ...
}

I feel like you need to consider the various consumption cases for hyperapp

Since hyperapp ends up being packaged as a UMD module, should we follow the module.d.ts UMD example from the TypeScript handbook?

Is this good? I ask because attributes can only be a string, number, function, null/undefined, an object in the case of key=style.

• Less naive VNodeData interface

Here, as you wish, we can be really straight but generics :

export interface VNodeData {
  [key: string]: string | number | Function | null
               | undefined | Object //as everything is object this is like all : `any`
}

Or we can dive into the horrific (like did in @Types/React), add a type to every attrs 👎
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L2101

@Swizz I don't know how to write this file, so I am only asking to learn. Please make the typings in the best way you know. Size doesn't matter.

Size doesn't matter, but I dont want you to be in charge of a monster. The react types is too too.

Here, I think we can allow the use of any. I dont want to maintain a complete list of HTML attribute, and how about custom ones ? And how about new ones ?
An attribute is nothing more a key and a value, and a value can be everything so any.

@nippur72 Do you agree ?

edit : Preact was on the thoughts to type all the attrs too 😕
https://github.com/developit/preact/blob/master/src/preact.d.ts

Only for JSX. For Vnode they let the same at us

interface VNode {
  nodeName:ComponentConstructor<any, any>|string;
  attributes:{[name:string]:any};
  children:VNode[];
  key:string;
}

@Swizz attribute typing is a cool feature that lets you spot a lot of errors at compile time, so we should attempt to cover it. We don't have to implement it from scratch, we can easily adapt react or preact (their typings are MIT licensed). Custom attributes are not a problem: they do appear in custom elements which in turn are extensions of native HTML elements; their typings should be automatic if the component is written the right way.

The only problem I see is with events when an action is passed as event handler, e.g.

<button onclick={actions.some}></button>

but I think that can be solved by something like EventHanlder | Action

I think you can use the example I have from Picodom. We should absolutely avoid using any and prefer {} when possible.

For the JSX types, you could put them in a separate file (e.g. jsx.d.ts) and bring them in here using export * from "./jsx";. Might make ongoing maintenance a little easier since the massive typings of JSX will be separated from the core library typings. Just a thought

Is it VNodeData where lifecycle methods and keys would go? Would be nice to demonstrate those here too.

Why declare viewFunction's type here? and what is vnodeFunction?

It is requested into the Application interface

export interface Application<
    State,
    ActionsInterface extends Actions<State> | undefined,
    EventsInterface extends Partial<Events<State, ActionsInterface>> | undefined
  > extends Partial<Mixin<State, ActionsInterface, EventsInterface>> {
    root: HTMLElement
    view: viewFunction<State, ActionsInterface>
  }

and the render event

 export interface Events<
    State,
    ActionsInterface extends Actions<State> | undefined
  > {
 render:
      | (
          state: State,
          actions: ActionsInterface,
          view: viewFunction<State, ActionsInterface>,
          emit: emitFunction<any>
        ) => viewFunction<State, ActionsInterface>
  }

For vnodeFunction I wanted a way to express a function that return a vnode for h, and I wasnt sure about Component. But as the discution is closed, we can move into now.

export function h(
    tag: string | vnodeFunction,
    data?: VNodeData,
    children?: Array<number | string | VNode>
  ): VNode

In general, it's better to declare interfaces than types. You can make an interface like,

interface View<S, A> {
     (state: S, actions: A): VNode;
}

I feel like you need to consider the various consumption cases for hyperapp

I think you can use the example I have from Picodom. We should absolutely avoid using any and prefer {} when possible.

In general, it's better to declare interfaces than types. You can make an interface like,

interface View<S, A> {
     (state: S, actions: A): VNode;
}

I feel like this is begging for a named interface. TypeScript produces better error messages against named interfaces rather than anonymous types.