Would you be willing to write more extensive documentation for this?

[Evertt]

I really really like this library. However I have some questions about its usage and since I don't want to bombard you with questions I was wondering if you'd be willing to write some more extensive documentation for this library?

[HerringtonDarkholme]

Actually, documentation is intentionally avoided.

Please, don't use it in production.

TypeScript isn't designed for type level programming. Though you can do experiment like this project, it does not mean you should. The heavy usage of intersection type and function overloading falls way beyond valid use of TypeScript. On the other hand, Vue and its related libraries are not designed to be even type checkable! Combining two unorthodox usage into one is almost heretic.

I don't want to see the community think Vue + TS = freak. That's why I don't promote this library.

[HerringtonDarkholme]

For comparison, you can look at how redux works with flow.

Redux opts for a more approachable API for both type checker and library users. They requires user to explicitly list all actions payload. So while it is more verbose than Vuex, it is, well, more typable in ergonomic sense.

Vuex and this library build action payload type implicitly. This means: 1) No static type at all. This is Vuex. 2) Typed via type level acrobatics. This is kilimanjaro.

Which one is better for JavaScript community? Definitely the first one, given JS' dynamic type nature.

[Evertt]

I don't understand why you don't consider implicitly typed to be awesome. It means more safety without the added writing of code. Isn't that the holy grail?

[jmcclell]

I surmise that the fear is that It's introducing a sizable dose of voodoo into a language already capable of its own share of black magic. In other words, when the type system is deeply integrated into the language itself (eg: Scala, Haskell) type level programming is awesome. When the type system is bolted on top of a language never intended to be statically typed, however, pushing that type system to its limits, while seriously cool, gives rise to situations whereby it works until it doesn't. Unfortunately, when it doesn't, it may be very difficult to debug and, perhaps, even impossible to fix given the constraints of the relationship between the type system and the underlying language.

I'm not an expert with TS or Vue, just looking into it for a project, but I can understand @HerringtonDarkholme's reservations given that the goals of TS appear to be aligned with providing basic type safety rather than providing a turing complete, provably sound type system which is what you ideally want if you're going to do super awesome stuff like this. That is, I'm sure he thinks it's awesome, he just realizes it's probably not wise to promote it as valid/best practice given the current state of TS.

All that said, this is really cool.

[HerringtonDarkholme]

@jmcclell Exactly! I really appreciate your understanding!

[jmcclell]

I don't, and hope I didn't put words in your mouth, but wanted to offer @Evertt a perspective on why the holy grail is, perhaps, still out of reach! Great work regardless.

[Evertt]

@jmcclell I think @HerringtonDarkholme didn't want to say "hey don't pretend like you know me", but instead was trying to say "I feel understood". Is that right @HerringtonDarkholme?

In any case I appreciate the extra explanation. I think I kind of guessed something like that already, I was just not willing to accept it. You see ever since I switched from programming mainly in PHP to programming mainly in Swift I have fallen in love with static typing. And I especially love when the compiler is able to infer as much as possible (without needing to make assumptions in ambiguous situations). That to me is the holy grail of safe and concise programming. So when I saw that this library was doing exactly that I just didn't want to accept the possibility that it might not actually be the dream I was looking for.

Now I'm just hoping for WebAssembly to become awesome and for Swift to become compilable to WebAssembly.

[HerringtonDarkholme]

@jmcclell So sorry I express myself wrong. I really appreciate your words.

@Evertt Thank you for explanation!

[jmcclell]

@HerringtonDarkholme No worries at all!

[HerringtonDarkholme]

Some my dogfood experience with this library.

Kilimanjaro requires splitting modules, and modules must be topological sortable. So that all types defined can flow implicitly. I found it quite hard in real world.

I also found it quite hard to introduce Kilimanjaro's idea to my colleagues. They either don't have notion of types (Alas, JSer/PHPer) or are just new to TypeScript. Understanding generic is already quite hard for them.

Type level correctness is basically not enough for program like vuex. I cannot encode every business logic in types. So writing test is more effective here. And because vuex relies on pure JavaScript or can be easily mocked (e.g. ajax, http://sinonjs.org/docs/#server). Running test is blazing fast! Writing test is also not hard because logic can be easily abstracted to function and I can test it with expected value/action, unexpected value/action and edge case value. In summary, the ROI of writing test is higher than type checking.

It might be easier to refactor if we have statically typed vuex. Yet testing can also help maintenance too.

[ajeffrey]

would it be possible to safely use kilimanjaro if I avoided straying outside of idiomatic Vuex? I'm working on a Vuex/Typescript app and it's starting to get big enough that static typing would have a massive positive effect on my productivity and confidence in refactoring. I go out of my way to "colour within the lines" of Vue/Vuex's proscribed design patterns.

I guess what I'm asking is, what kind of use cases do you think will cause kilimanjaro to fall down?