Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix the export error #77

Merged
merged 7 commits into from
Jan 8, 2018
Merged

Fix the export error #77

merged 7 commits into from
Jan 8, 2018

Conversation

andreiglingeanu
Copy link
Collaborator

@andreiglingeanu andreiglingeanu commented Dec 15, 2017

Fixes #76

This will:

  • properly export update function
  • make MapAndSetOperators generic

cc. @kolodny

@coveralls
Copy link

coveralls commented Dec 15, 2017

Coverage Status

Coverage remained the same at 100.0% when pulling 202320d on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

@kolodny
Copy link
Owner

kolodny commented Dec 17, 2017

I'm fine with this PR, but is there any way to include a ts build/check step to npm test so that regressions on the .d.ts file don't come back to bite us?

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks better than what's in DefinitelyTyped.
Have you considered using overloading instead of a union of queries? This would prevent you from e.g. using an ArrayOperator on something that's not an array.

declare function update<T>(data: ReadonlyArray<T>, query:  update.ArrayOperator<T>): ReadonlyArray<T>
declare function update<T>(data: ReadonlySet<T>, query: { $add: ReadonlyArray<T> } | { $remove: ReadonlyArray<T> }): ReadonlySet<T>
declare function update<K, V>(data: ReadonlyMap<K, V>, query: { $add: ReadonlyArray<[K, V]> } | { $remove: ReadonlyArray<K> }): ReadonlyMap<K, V>
declare function update<K extends string, T extends { readonly [key in K]: boolean }>(data: T, query: { $toggle: ReadonlyArray<K> }): T;
...etc...

...although I can't figure out how you would strongly-type nested queries without conditional types (microsoft/TypeScript#12424).

If you're interested in testing, dtslint can be run outside of DefinitelyTyped. (But make sure to remove the // Type definitions for immutability-helper header or it will think you're on DefinitelyTyped.)

index.d.ts Outdated
// Type definitions for immutability-helper
// Project: Immutability helper

export default update
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

@andreiglingeanu andreiglingeanu Dec 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, thanks

@andreiglingeanu
Copy link
Collaborator Author

andreiglingeanu commented Dec 20, 2017

Oh, thanks. I'll get over everything a covert it into a commit soon.

And yes, I have seen microsoft/TypeScript#12424 while researching a way to provide stronger types for the lib. I believe overloading is way better than having unions, thanks for that. But yeah, without conditional types we are indeed loosing some information about the generic type <T>.

@andreiglingeanu
Copy link
Collaborator Author

andreiglingeanu commented Dec 31, 2017

Hey @kolodny, now you can run npm run test-dtslint in order to verify the validity of the types, sorry for not getting them correct from the first pass

@andy-ms could you please see if typings are in a better shape now?

@coveralls
Copy link

coveralls commented Dec 31, 2017

Coverage Status

Coverage remained the same at 100.0% when pulling af16399 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

2 similar comments
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling af16399 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling af16399 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

@ghost
Copy link

ghost commented Jan 2, 2018

@andreiglingeanu It looks good, but it doesn't seem like it will allow you to push to an array that's nested as a property? You would have to include $push in the Query type for that to work.

@andreiglingeanu
Copy link
Collaborator Author

andreiglingeanu commented Jan 3, 2018

Oh, my bad! For some kind of a reason I thought the array would be only on the first level.

I'll fix the typings, thanks.

@andreiglingeanu
Copy link
Collaborator Author

@andy-ms pushed the change. Now arrays, Map & Sets can be nested into objects. Does that look okay?

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 77b8957 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

3 similar comments
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 77b8957 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 77b8957 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 77b8957 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

index.d.ts Outdated
| {$splice: Array<[number, number]>}
| {$splice: Array<[number, number]>}

type MapAndSetOperators<T> = {$add: any[]} | {$remove: string[]}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a Map, shouldn't this be $remove: K[] and $add: [K, V][]?
Similarly, for a Set you would remove/ add T, not string.

@andreiglingeanu
Copy link
Collaborator Author

andreiglingeanu commented Jan 3, 2018

Yeah, missed that. A strong limitation is that I won't be able to type properly the nested Map in a Query without conditional types, but we should be good for now.

@coveralls
Copy link

coveralls commented Jan 3, 2018

Coverage Status

Coverage remained the same at 100.0% when pulling a0ab40c on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

@coveralls
Copy link

coveralls commented Jan 3, 2018

Coverage Status

Coverage remained the same at 100.0% when pulling fe471d4 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling fe471d4 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

index.d.ts Outdated
| Tree<T>
| ObjectOperators<T>
| ArrayOperators<T>
| SetOperators<T>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would just be ArrayOperators<any> and SetOperators<any> since T here is the type of the object itself, not the type of its elements.

@coveralls
Copy link

coveralls commented Jan 3, 2018

Coverage Status

Coverage remained the same at 100.0% when pulling bcd4248 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last comment

index.d.ts Outdated
query: ArrayOperators<T>,
): ReadonlyArray<T>

declare function update<T>(data: T, query: Query<T>): object
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be the last overload so that the ReadonlySet and ReadonlyMap ones are tried first.

index.d.ts Outdated
| {$toggle: Array<keyof T>}
| {$unset: Array<keyof T>}
| {$merge: Partial<T>}
| {$apply: (old: T) => any}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be => T?

@andreiglingeanu
Copy link
Collaborator Author

andreiglingeanu commented Jan 3, 2018

@andy-ms Thanks, learned a lot :)

@coveralls
Copy link

coveralls commented Jan 3, 2018

Coverage Status

Coverage remained the same at 100.0% when pulling bbf0b56 on andreiglingeanu:patch-1 into 486a7e0 on kolodny:master.

@kolodny kolodny merged commit 792f5ef into kolodny:master Jan 8, 2018
@kolodny
Copy link
Owner

kolodny commented Jan 8, 2018

Awesome! Thanks for this. I'm going to add tslint to the build process so that it runs on travis. Are there any administrative steps to take after making a release, for example should there be a PR to remove immutability-helper from DefinitelyTyped

@kolodny
Copy link
Owner

kolodny commented Jan 8, 2018

Also I imagine that #79 can be closed, is that correct?

@andreiglingeanu
Copy link
Collaborator Author

Awesome!

@kolodny after we PR DefinitelyType yes, #79 can be closed

@kolodny
Copy link
Owner

kolodny commented Jan 8, 2018

Great, published to v2.6.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants