Add support for object type spread about babel-plugin-tcomb HOT 11 CLOSED

IMO the better option would be to define a helper function (actually a new custom tcomb combinator) and inject it when needed, like assert or extend (see here https://github.com/gcanti/babel-plugin-tcomb/blob/master/src/index.js#L64). Since tcomb types are fully introspectable at runtime, you should be able to implement the required complex logic.

from babel-plugin-tcomb.

Gave it a try ☝️

from babel-plugin-tcomb.

These should be converted into a tcomb intersection

Based on this comment they are pretty different from intersections

from babel-plugin-tcomb.

Based on this comment they are pretty different from intersections

Ah, that's true. I was a bit quick on the trigger.

Seems like doing t.interface.extend() will be the right thing to do?

from babel-plugin-tcomb.

Updated PR to do interface.extend instead.

from babel-plugin-tcomb.

I'm afraid is not well suited: from the documentation of tcomb you linked

Note. Repeated props are not allowed (unless they are strictly equal)

Also, in absence of official documentaton (!), the following rules seem to apply

• every property from spread becomes optional
• every property before non-exact spread becomes mixed
• properties after spread stay the same
• $Exact changes the rules above

so the behavior is way different from t.interface.extend

from babel-plugin-tcomb.

Thank you so much for the feedback!

Aha. I misunderstood

Alternatively you can use the t.interface.extend(mixins: Array, options?: string | Options) => TcombType function:

To mean that I could use t.interface.extend to allow repeated props.

every property from spread becomes optional

Would an approach be to iterate over the properties in the interface being spread and make them into maybe by default, but not when the interface is $Exact<>?

every property before non-exact spread becomes mixed

We could do this by splitting properties into two groups, before and after spread and making those before spread mixed ?

And then maybe do some hand-wrangling to create a new interface directly?

from babel-plugin-tcomb.

Would a way to simplify this be to add an option to .extend() that allow overwrites that gets passed to mixin(). Or would you rather not allow this in plain tcomb ?

from babel-plugin-tcomb.

I've updated the PR and I think it takes in to account all of the strange rules surrounding object spread. How do you feel about the code, and the separation between what is done at compile time vs runtime?

from babel-plugin-tcomb.

How do you feel about the code, and the separation between what is done at compile time vs runtime?

Seems a good balance. Let me know when you consider the PR mergeable. If you agree I'll publish this feature tagged as Experimental for now

From the CHANGELOG file: A feature tagged as Experimental is in a high state of flux, you're at risk of it changing without notice.

because

• the upstream feature seems still unstable
• the feature must be tested in real world scenarios

from babel-plugin-tcomb.

👍

I've bumped the version and updated the changelog. Is there anything I've missed? If not I feel like its mergable.

from babel-plugin-tcomb.