Add typings file

[jonaskello]

This PR is just to support the discussion in #31.

[andrejewski]

🍥

[andrejewski]

One issue with generic V is that for raj/runtime view is <State, Message>(state: State, dispatch: Dispatch<Message>): void as Raj does nothing with the return value. The return value of view is given meaning in the view libraries such as raj-react. Typing this we either over generalize the core framework or have multiple Program definitions that end-users would need to reconcile.

I'm not saying this is wrong, just something to consider.

[jonaskello]

Yes, this only makes sense if we consider raj-react or similar packages. I've already made typings for raj-react so I'll make a similar PR to that repo in order to put the generic V in context for discussing these typings.

[jonaskello]

So the typings for raj-react to put theV in context are here. Not sure if it is really needed, maybe it could be done somehow without V.

[mindplay-dk]

@jonaskello is there any particular reason why the type-arguments occur in inconsistent order? I'd suggest making them consistent with Program, e.g. S, M, V - specifically:

View<S,M,V>
Update<S,M>

I'd also personally prefer names like TState, TMessage, TView as single letters are not very semantic and the T prefix is idiomatic to Typescript and helps you visually spot the type-variables when reading over the type-declarations.

By the way, Raj made no sense to me until I saw these type-declarations 😉

[jonaskello]

Yes, I agree we should make the order of type params consistent if this would ever get merged.

Regarding TView, having done a lot of C# that is what I'm most used to too. However I've seen the typescript community use single letters a lot (for example, the official typings for both redux and react have single letters IIRC). I've found that having the longer names can sometimes make reading the typings more difficult since it becomes a bit verbose, especially when the params are repeated many times on the same line. With longer names, each type parameter become more clear but the the line as a whole becomes harder to parse. In this particular case I would say that the meaning of the letters is quite obvious so I would probably stick with single letters, but I have no strong opinion on this.

Btw, I implemented my own version of raj in my project and made a raj-logger as a fork of redux-logger and it is working out quite well. The downside to having no types in raj is that it is hard to make community packages for it like raj-logger since that package would have to import the raj package typings, which are non-existent at this point.

If anyone is familiar with the process of gettings types published as @types packages they are welcome to take these typings and publish them as @types/raj. This might be the best way to go as it seems the raj author is reluctant to include the typings file directly in the package.

[mindplay-dk]

Just my opinion, but I'm okay with T as a convention for a single, unconstrained type - and there's a lot of that going around in the community and in Typescript's built-in types. Usually the meaning of the type-argument T is completely plain, e.g. Box<T>, where T is simply "the type". Once you introduce several single letters, their meaning becomes more succint - there's a bit of guesswork involved when you first lay eyes on the thing, and the single letters are much harder for me to parse than actual words.

For example, I instantly thought M was for "model", which is common, and took me a minute to realize it's "message" in this architecture - that was confusing.

[mindplay-dk]

@jonaskello did you give up on this? (or did it land somewhere else?)

@andrejewski I wish you were more receptive to this. I like the idea of Raj, but I'm basically "on hold" waiting for proper type-definitions - this is likely a roadblock to anyone using TS, since adding correct types for this isn't trivial. Investing in this currently seems too risky for a large-scale project.

Just an aside, but many IDEs by now exploit type-declarations well enough to provide better validation, auto-completion and navigation, even in plain JS projects - so this benefits not only TS users.