Added Flow Typing #778
|
|
@ -10,5 +10,6 @@
|
||||||
[options]
|
[options]
|
||||||
suppress_comment=\\(.\\|\n\\)*\\$FlowFixMe
|
suppress_comment=\\(.\\|\n\\)*\\$FlowFixMe
|
||||||
suppress_comment=\\(.\\|\n\\)*\\$FlowIssue
|
suppress_comment=\\(.\\|\n\\)*\\$FlowIssue
|
||||||
|
module.name_mapper='^constants\(.*\)$' -> '<PROJECT_ROOT>/js/constants\1'
|
||||||
|
|
||||||
[strict]
|
[strict]
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
|
|||||||
// @flow
|
// @flow
|
||||||
|
|
||||||
import * as types from "../../constants/action_types";
|
import * as types from "constants/action_types";
|
||||||
|
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
|
|||||||
import * as modalTypes from "../../constants/modal_types";
|
import * as modalTypes from "constants/modal_types";
|
||||||
|
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
|
|||||||
|
|
||||||
// $FlowIssue: Flow cannot find election
|
// $FlowIssue: Flow cannot find election
|
||||||
const { remote } = require("electron");
|
const { remote } = require("electron");
|
||||||
|
|
@ -48,6 +48,7 @@ const defaultState: AppState = {
|
||||||
|
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
|
|||||||
hasSignature: false,
|
hasSignature: false,
|
||||||
badgeNumber: 0,
|
badgeNumber: 0,
|
||||||
volume: Number(sessionStorage.getItem("volume")) || 1,
|
volume: Number(sessionStorage.getItem("volume")) || 1,
|
||||||
|
|
||||||
|
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
|
|||||||
downloadProgress: undefined,
|
downloadProgress: undefined,
|
||||||
upgradeDownloading: undefined,
|
upgradeDownloading: undefined,
|
||||||
upgradeDownloadComplete: undefined,
|
upgradeDownloadComplete: undefined,
|
||||||
|
|
|
||||||
|
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
thoughts on all upper case for types? thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on Any particular reason are these optional properties that we don't set on `defaultState`? IMO optional properties should generally be avoided.
(also, state types will generally need to be exported so they can be used by selectors) (also, state types will generally need to be exported so they can be used by selectors)
Isn't this just Isn't this just `?string`
Isn't this an unsealed Isn't this an unsealed `Object` or `null`? (not clear on Flow syntax for this: `?{}`?)
If this is the return value for an interval call, I believe it is If this is the return value for an interval call, I believe it is `?number`
I don't remember what's put in this but I'm just hating on all of your usage of I don't remember what's put in this but I'm just hating on all of your usage of `mixed` at this point.
I believe mixed is the correct way for to indicate Object I believe mixed is the correct way for to indicate Object
Also also, this should be a sealed object. Also also, this should be a sealed object.
optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though. The one edge case I could see, and I will double check this, is, as I was saying in slack: downloadProgress?: number could be a number or undefined In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field. optional properties can be thought of as implicitly there, but set to "undefined". I am more than happy to add them, though.
The one edge case I could see, and I will double check this, is, as I was saying in slack:
downloadProgress?: number could be a number or undefined
downloadProgress: ?number could be a number or undefined or null
In order to remove optional fields, we would have to either allow null or determine a non-null default value for each field.
me too, i'll figure it out me too, i'll figure it out
I agree, I meant to bring this up, we also need to figure out how to properly do naming. I agree, I meant to bring this up, we also need to figure out how to properly do naming.
ah i didn't realize that, thanks. ah i didn't realize that, thanks.
yes, thanks yes, thanks
I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt I am going to go through each of these one by one to determine whether or not I can add null, or some other initial value to them instead of undefined, however, there inevitably will be some fields that are initialized as undefined (given what we decided in terms of having no optional types + using undefined as a distinct value). Does this seem alright to you guys? @kauffj @seanyesmunt
Yes, given that the existing behavior a property not explicitly set on Yes, given that the existing behavior a property not explicitly set on `defaultState` is to default to `undefined`, it makes sense to set values to `undefined` rather than `null` to match existing behavior.
Got it. Makes sense. I'm cool with this. Got it. Makes sense. I'm cool with this.
@liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/ @liamcardenas I do not think that is correct https://flow.org/en/docs/types/mixed/
|
|||||||
thoughts on all upper case for types?
Any particular reason are these optional properties that we don't set on
defaultState? IMO optional properties should generally be avoided.(also, state types will generally need to be exported so they can be used by selectors)
Isn't this just
?stringIsn't this an unsealed
Objectornull? (not clear on Flow syntax for this:?{}?)If this is the return value for an interval call, I believe it is
?numberI don't remember what's put in this but I'm just hating on all of your usage of
mixedat this point.