-
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
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
export interface FluxStandardAction { | ||
/** | ||
* The `type` of an action identifies to the consumer the nature of the action that has occurred. | ||
* Two actions with the same `type` MUST be strictly equivalent (using `===`) | ||
*/ | ||
type: string | symbol; | ||
/** | ||
* The optional `payload` property MAY be any type of value. | ||
* It represents the payload of the action. | ||
* Any information about the action that is not the type or status of the action should be part of the `payload` field. | ||
* By convention, if `error` is `true`, the `payload` SHOULD be an error object. | ||
* This is akin to rejecting a promise with an error object. | ||
*/ | ||
payload?: any; | ||
/** | ||
* 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 commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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 commentThe 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 commentThe 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 commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would like to keep it as simple There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 I'm not sure how to exclude 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 commentThe reason will be displayed to describe this comment to others. Learn more. When user enables There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a way to disambiguate between |
||
*/ | ||
error?: boolean | any; | ||
/** | ||
* The optional `meta` property MAY be any type of value. | ||
* It is intended for any extra information that is not part of the payload. | ||
*/ | ||
meta?: any | ||
} | ||
|
||
/** | ||
* Alias to FluxStandardAction for shorthand | ||
*/ | ||
export type FSA = FluxStandardAction; | ||
|
||
/** | ||
* Returns `true` if `action` is FSA compliant. | ||
*/ | ||
export function isFSA(action: any): boolean; | ||
|
||
/** | ||
* Returns `true` if `action` is FSA compliant error. | ||
*/ | ||
export function isError(action: any): boolean; |
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 publishedfiles
? I would rather you move this to the root so that this array can just be: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.