-
Notifications
You must be signed in to change notification settings - Fork 142
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
Add typings to the repo #33
Conversation
bump @acdlite |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@unional this LGTM, thanks for the contribution! A major overhaul was recently merged so would you mind rebasing and re-generating the typings file? Thanks.
I have updated it. They typings file is basically the same. I just further clean up the comments as now VSC supports tilde in the intelliSense. |
2 similar comments
@@ -3,6 +3,7 @@ | |||
"version": "0.6.1", | |||
"description": "A human-friendly standard for Flux action objects", | |||
"main": "lib/index.js", | |||
"typings": "src/index.d.ts", | |||
"files": [ | |||
"lib" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't the index.d.ts
need to be in the published files
? I would rather you move this to the root so that this array can just be:
[
"lib",
"index.d.ts"
]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do that. Putting the file directly next to the source allows editor (VS Code) to pick it up automatically.
* The optional `error` property MAY be set to true if the action represents an error. | ||
* An action whose `error` is true is analogous to a rejected Promise. | ||
* By convention, the `payload` SHOULD be an error object. | ||
* If `error` has any other value besides `true`, including `undefined` and `null`, the action MUST NOT be interpreted as an error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this last statement is [strictly] true, since the tests have a line where the error
object is an instanceof
Error. see: https://github.com/acdlite/flux-standard-action/blob/master/test/isFSA-test.js#L31
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is directly from the README. Do you want to update that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point - it should be updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though which one is defined as correct is still debatable imho [b/c we have a test enforcing one way and documentation mentioning another]. Thoughts @acdlite?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @yangmillstheory for your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think more people have probably read the README than studied the test - at least that's my personal experience with this. I would vote for aligning the test with the documentation, but the ultimate goal would be to pick one of those sources of truth and stick with it.
Also, it's been a while since I've done TypeScript, but shouldn't this be boolean
, since no other value is meaningful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to keep it as simpleboolean
. But by README, I assume you allow it to be other values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's "allowed", but not meaningful. In TypeScript we should have this be
type?: boolean
so that users know at compile-time that the only meaningful values are true
, false
, undefined
, or null
.
I'm not sure how to exclude null
, since ?
seems to allow it:
interface Foo { foo?: boolean }
const foo: Foo = { foo: null } // no compiler errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When user enables strictNullCheck
, it is excluded from ?
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to disambiguate between null
and undefined
in code? I think 2.0 has Null
and Undefined
.
@JaKXz I update
|
Sorry @unional for the delay - I'm still on the fence about the |
No problem. It is a convention that the I can move it to root if you still want that. |
@unional thanks so much for your patience! I've had some offline conversations about this and it LGTM - I'll update the README and publish v1.1.0 soon. |
I have some update to the typings that can make it more useful. |
Would you be interested in accepting this PR so TypeScript user can get the typings definition directly?
Thanks. 🌷