Add type guards #43

SamVerschueren · 2018-03-29T16:10:06Z

I don't have much time now, will have another look tomorrow if we can do some more simplifications with type guards.

SamVerschueren · 2018-03-29T17:33:05Z

Added some more typeguards. The nice thing is that TypeScript now uses the correct type when using is inside an if-else statement for example.

if (is.nativePromise(x)) {
   // `x` is now typed as Promise
}

I believe I can do some more improvements, so PR is WIP.

SamVerschueren · 2018-03-30T05:57:57Z

source/index.ts

 	export const object = (value: any) => !nullOrUndefined(value) && (function_(value) || isObject(value));
-	export const iterable = (value: any) => !nullOrUndefined(value) && function_(value[Symbol.iterator]);
-	export const generator = (value: any) => iterable(value) && function_(value.next) && function_(value.throw);
+	export const iterable = <T = any>(value: any): value is Iterator<T> => !nullOrUndefined(value) && function_(value[Symbol.iterator]);


This allows you to write the following

if(is.iterable<string>(foo)) { const result = foo.next(); // `result` is now an `IteratorResult` of type `string` }

If you want I can remove the generic though as it's not really part of the check. It actually just infers the type of the items inside the Iterator.

SamVerschueren · 2018-03-30T05:58:52Z

source/index.ts


-	export const nativePromise = isObjectOfType(TypeName.Promise);
+	export const nativePromise = isObjectOfType<Promise<any>>(TypeName.Promise);


I couldn't figure out how I could make this one generic, like the is.promise check below. Might be weird to be able to pass in a type to .promise but not to .nativePromise.

SamVerschueren · 2018-03-30T05:59:55Z

tsconfig.json

@@ -7,6 +7,11 @@
 		"declaration": true,
 		"pretty": true,
 		"newLine": "lf",
+		"lib": [


Had to set this to be able to use SharedArrayBuffer. Should we use es2015 instead because that's our main target?

Should we use es2015 instead because that's our main target?

Yes

SamVerschueren · 2018-03-30T06:00:41Z

Added some inline comments. I'm not sure about the generic stuff though. Feel free to provide feedback!

sindresorhus · 2018-03-31T11:33:50Z

Added some more typeguards. The nice thing is that TypeScript now uses the correct type when using is inside an if-else statement for example.

Could you document this? Seems like a nice feature users might not be aware of.

debuggerpk · 2018-04-01T09:26:16Z

source/index.ts

@@ -1,5 +1,12 @@
 import * as util from 'util';

+type TypedArray = Int8Array | Uint8Array | Uint8ClampedArray | Int16Array | Uint16Array | Int32Array | Uint32Array | Float32Array | Float64Array;


if you want, i can add a commit to this.

Although it fixes the issue, the type is incorrect. Now TypedArray is defined as an array of Int8Array or Uint8Array, etc.

What does work however, is the following

type TypedArray = (Int8Array | Uint8Array | Uint8ClampedArray | Int16Array | Uint16Array | Int32Array | Uint32Array | Float32Array | Float64Array) & Array<number>;

This is ugly though. Will have a look as to why this error is caused.

AFAIK, the error message "Cannot invoke an expression whose type lacks a call signature"" is by design. see microsoft/TypeScript#7294 .

I think I'm going to leave it as is for now. It's explained in the issue that you referenced, this is by design. If you know what type it will be, it would be safer to use is.int8Array or one of the others. Thanks for letting me know, learned something new today :).

SamVerschueren · 2018-04-01T11:38:54Z

I thought more about the generic functions we expose, e.g. the following

if (is.promise<number>(foo)) {
   const value = await foo;
   // value is of type number
}

I don't think we should do that. The only thing that is does, is check the type and infer the type correctly. It's not up to is to do more than that. If users type there values correctly, all of it will go automatically.

const foo: Promise<number> | undefined = someValue;

if (is.promise(foo)) {
   const value = await foo;
   // value is of type number
}

If they didn't specify the types correctly, they can always type it themselves.

// foo is of type any

if (is.promise(foo)) {
   const value: number = await foo;
   // value is of type number
}

So I believe we should get rid of the generics to the outside world because it's not up to is to enforce the type the wrapper resolves to. We currently only have generics exposed for is.promise and is.iterable.

debuggerpk · 2018-04-01T11:42:20Z

@SamVerschueren thank you for kind reply. It makes sense. I saw the call to review by @sindresorhus on twitter, and looked at it. this particular gave me quite a headache a few weeks ago while upgrading a projecting from js to ts. thank you again.

SamVerschueren · 2018-04-03T05:54:32Z

readme.md

@@ -27,6 +27,32 @@ is.number(6);
 //=> true
 ```

+When using `is` together with TypeScript, [type guards](http://www.typescriptlang.org/docs/handbook/advanced-types.html#type-guards-and-differentiating-types) are being used to infer the correct type inside if-else statements.


In VSCode, type inference also works in JavaScript. Don't think we should document this as it's IDE specific.

SamVerschueren · 2018-04-03T05:55:24Z

@sindresorhus Processed feedback. Let me know if you have some more feedback.

sindresorhus · 2018-04-03T17:05:53Z

I don't think we should do that. The only thing that is does, is check the type and infer the type correctly. It's not up to is to do more than that. If users type there values correctly, all of it will go automatically.

Late answer, but yes, I agree.

sindresorhus · 2018-04-03T17:06:56Z

Yay! Such strong typing 💪 Quality work as always, Sam.

Add type guards for better type inference

ff99cea

SamVerschueren force-pushed the type-guards branch from 00e96ab to ff99cea Compare March 30, 2018 05:54

SamVerschueren commented Mar 30, 2018

View reviewed changes

styfle approved these changes Mar 31, 2018

View reviewed changes

debuggerpk reviewed Apr 1, 2018

View reviewed changes

Change TS lib

e3aa269

SamVerschueren force-pushed the type-guards branch from c3d555c to 4cbec28 Compare April 3, 2018 05:33

Remove generics

39c2ca2

SamVerschueren force-pushed the type-guards branch 3 times, most recently from 163a1d7 to 96ca271 Compare April 3, 2018 05:52

Document type guards

5d54aa7

SamVerschueren force-pushed the type-guards branch from 96ca271 to 5d54aa7 Compare April 3, 2018 05:53

SamVerschueren commented Apr 3, 2018

View reviewed changes

sindresorhus merged commit 8894dbe into master Apr 3, 2018

sindresorhus deleted the type-guards branch April 3, 2018 17:06

sindresorhus mentioned this pull request Apr 3, 2018

Use type guards #35

Closed

SamVerschueren mentioned this pull request May 2, 2018

Improve TS code by adding generics and removing any where applicable #49

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add type guards #43

Add type guards #43

SamVerschueren commented Mar 29, 2018

SamVerschueren commented Mar 29, 2018

SamVerschueren Mar 30, 2018

SamVerschueren Mar 30, 2018

SamVerschueren Mar 30, 2018

sindresorhus Mar 31, 2018

SamVerschueren commented Mar 30, 2018

sindresorhus commented Mar 31, 2018

debuggerpk Apr 1, 2018 •

edited

Loading

debuggerpk Apr 1, 2018

SamVerschueren Apr 1, 2018

debuggerpk Apr 1, 2018

SamVerschueren Apr 3, 2018

SamVerschueren commented Apr 1, 2018

debuggerpk commented Apr 1, 2018

SamVerschueren Apr 3, 2018

SamVerschueren commented Apr 3, 2018

sindresorhus commented Apr 3, 2018

sindresorhus commented Apr 3, 2018


		export const nativePromise = isObjectOfType(TypeName.Promise);
		export const nativePromise = isObjectOfType<Promise<any>>(TypeName.Promise);

		@@ -1,5 +1,12 @@
		import * as util from 'util';

		type TypedArray = Int8Array \| Uint8Array \| Uint8ClampedArray \| Int16Array \| Uint16Array \| Int32Array \| Uint32Array \| Float32Array \| Float64Array;

Add type guards #43

Add type guards #43

Conversation

SamVerschueren commented Mar 29, 2018

SamVerschueren commented Mar 29, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SamVerschueren commented Mar 30, 2018

sindresorhus commented Mar 31, 2018

debuggerpk Apr 1, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SamVerschueren commented Apr 1, 2018

debuggerpk commented Apr 1, 2018

Choose a reason for hiding this comment

SamVerschueren commented Apr 3, 2018

sindresorhus commented Apr 3, 2018

sindresorhus commented Apr 3, 2018

debuggerpk Apr 1, 2018 •

edited

Loading