Assertions on object destructuring

[NervosaX]

This is possibly more of a support question, as there are a lot of holes in my knowledge. I have the following:

type TestType = {
    input: Object,
    output: Function
}

function foo({output}: TestType) {
    output();
}

foo({
    input: {},
    output: function() {}
});

flow: ok
tcomb: [tcomb] Invalid value undefined supplied to { output }: TestType/input: Object

So I thought make the items optional:

type TestType = {
    input: ?Object,
    output: ?Function
}

function foo({output}: TestType) {
    output();
}

foo({
    input: {},
    output: function() {}
});

flow: function call. Function cannot be called on possibly undefined value
tcomb: ok

Both errors kind of make sense from the different perspectives... Is there a way to satisfy both assertions, or am I destined to have to only create a type for each combination of destructured arguments?

[gcanti]

flow: ok
tcomb: [tcomb] Invalid value undefined supplied to { output }: TestType/input: Object

This is a bug, thanks for reporting

[gcanti]

Released a fix in https://github.com/gcanti/babel-plugin-tcomb/releases/tag/v0.3.21

@NervosaX out of curiosity, why are you using Flow and babel-plugin-tcomb?
(I'm doing a kind of poll in order to know the several use cases and if they apply to my new proof of concept)

[NervosaX]

@gcanti Wow, quick fix, thanks :)

I'm actually only just using the two in the last couple of days, hence my current activity. My thoughts so far:

1. I like the immediate feedback on code change. It's quick to tell whether something -could- go wrong, rather than waiting for something to go wrong.

2. Builds can be lengthy due to quite a large code base. Flow gives me feedback before I have to wait for compiling to complete.

3. Using a plugin to add assertions is great for development... even better when it's a single line change to remove them. tcomb adds a lot of added safety at runtime... I definitely have noticed there are many things flow can't catch.

4. Why not? If I stick to one convention (flows) and either flow or tcomb stops being updated for whatever reason, I still have an exist strategy.

edit: 5) Flow + emacs gives me direct feedback in my editor as I'm coding!

[gcanti]

Sorry, I wasn't clear. I'm a happy Flow user myself (well, actually I don't plan to write vanilla JavaScript anymore), so for me Flow is the baseline: an indispensable tool. In my mind this plugin is just a kind of "gateway drug" to Flow.

Then I was wondering what Flow can't catch and how to fill those holes with a runtime type checking library, for example:

• validation to the edge of the system (API payload validation, form validation, etc...)
• runtime type introspection
• refinements

I definitely have noticed there are many things flow can't catch

Interesting, could you please elaborate a bit more? Are you talking about enforced immutability or something else?

[NervosaX]

Oh, I didn't doubt you were a flow user. You'd have to be to create a complicated plugin like this.

I definitely have noticed there are many things flow can't catch

Runtime errors, specifically. You can't always account for errors that will happen once your app has loaded and taken an unforeseen path. Specifically anything that is out of your control (third party libraries for example).

---

The same can be said of tcomb not being able to catch all. One thing I've noticed is that it can't handle passing arguments to a function I have no control of (which is understandable, we didn't add an assertion inside the function)... such as a third party dependency with no type definitions.

Ie, if I use the flow-typed definition for lodash (https://github.com/flowtype/flow-typed/blob/master/definitions/npm/lodash_v4.x.x/flow_v0.28.x-/lodash_v4.x.x.js) and call:

_.sum("hello");

Flow will return an error. At runtime, tcomb has not been able to assert the function internally, so it will fail at runtime.