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

Add typings to the repo #33

Merged
merged 6 commits into from
Nov 18, 2016
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions package.json
Original file line number Diff line number Diff line change
Expand Up @@ -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"
Copy link
Contributor

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"
]

Copy link
Contributor Author

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.

],
Expand Down
42 changes: 42 additions & 0 deletions src/index.d.ts
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.
Copy link
Contributor

@JaKXz JaKXz Oct 27, 2016

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

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

@JaKXz JaKXz Oct 27, 2016

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?

Copy link
Contributor

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?

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?

Copy link
Contributor Author

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.

Copy link

@yangmillstheory yangmillstheory Oct 28, 2016

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

Copy link
Contributor Author

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 ?.

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.

*/
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;