Added Flow Typing #778
2
.gitignore
vendored
|
|
@ -30,3 +30,5 @@ build/daemon.zip
|
|||
.vimrc
|
||||
|
||||
package-lock.json
|
||||
|
||||
.DS_Store
|
||||
|
|
|
|||
|
|
@ -3,4 +3,7 @@
|
|||
"es2015",
|
||||
"react"
|
||||
],
|
||||
}
|
||||
"plugins" : [
|
||||
"transform-flow-comments"
|
||||
]
|
||||
}
|
||||
|
|
|
|||
16
src/renderer/.flowconfig
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
[ignore]
|
||||
.*/node_modules/**
|
||||
|
||||
[include]
|
||||
|
||||
[libs]
|
||||
flow-typed
|
||||
|
||||
[lints]
|
||||
|
||||
[options]
|
||||
suppress_comment=\\(.\\|\n\\)*\\$FlowFixMe
|
||||
suppress_comment=\\(.\\|\n\\)*\\$FlowIssue
|
||||
module.name_mapper='^constants\(.*\)$' -> '<PROJECT_ROOT>/js/constants\1'
|
||||
|
||||
[strict]
|
||||
116
src/renderer/flowtype-plugin.js
Normal file
|
|
@ -0,0 +1,116 @@
|
|||
var spawnSync = require('child_process').spawnSync;
|
||||
var flow = require('flow-bin');
|
||||
var merge = require('lodash.merge');
|
||||
|
||||
var store = {
|
||||
error: null,
|
||||
flowOptions: [
|
||||
'status',
|
||||
'--color=always',
|
||||
],
|
||||
options: {
|
||||
warn: false,
|
||||
|
||||
formatter: function (errorCode, errorDetails) {
|
||||
return 'Flow: ' + errorCode + '\n\n' + errorDetails;
|
||||
},
|
||||
},
|
||||
};
|
||||
|
||||
|
||||
function flowErrorCode(status) {
|
||||
var error;
|
||||
switch (status) {
|
||||
|
|
||||
/*
|
||||
case 0:
|
||||
error = null;
|
||||
break;
|
||||
*/
|
||||
case 1:
|
||||
error = 'Server Initializing';
|
||||
break;
|
||||
case 2:
|
||||
error = 'Type Error';
|
||||
break;
|
||||
case 3:
|
||||
error = 'Out of Time';
|
||||
break;
|
||||
case 4:
|
||||
error = 'Kill Error';
|
||||
break;
|
||||
case 6:
|
||||
error = 'No Server Running';
|
||||
break;
|
||||
case 7:
|
||||
error = 'Out of Retries';
|
||||
break;
|
||||
case 8:
|
||||
error = 'Invalid Flowconfig';
|
||||
break;
|
||||
case 9:
|
||||
error = 'Build Id Mismatch';
|
||||
break;
|
||||
case 10:
|
||||
error = 'Input Error';
|
||||
break;
|
||||
case 11:
|
||||
error = 'Lock Stolen';
|
||||
break;
|
||||
case 12:
|
||||
error = 'Could Not Find Flowconfig';
|
||||
break;
|
||||
case 13:
|
||||
error = 'Server Out of Date';
|
||||
break;
|
||||
case 14:
|
||||
error = 'Server Client Directory Mismatch';
|
||||
break;
|
||||
case 15:
|
||||
error = 'Out of Shared Memory';
|
||||
break;
|
||||
}
|
||||
|
||||
return error;
|
||||
}
|
||||
|
||||
|
||||
function checkFlowStatus(compiler, next) {
|
||||
var res = spawnSync(flow, store.flowOptions);
|
||||
I think we should try to use I think we should try to use `let` and `const` to show if a variable will change or not
this file contains code from another repo, I don't want to change it too much because, once they update their npm package, we will be able to use that instead of this file. this file contains code from another repo, I don't want to change it too much because, once they update their npm package, we will be able to use that instead of this file.
What is the other module? Seems simple enough, do we need to use it? What is the other module? Seems simple enough, do we need to use it?
this is a pretty decently maintained package: https://github.com/zhirzh/flow-babel-webpack-plugin I'd like to be able to include other changes made by that developer if possible. I left an issue about updating the NPM package. If it looks abandoned after enough time then we should look at bringing this in-house. I expect to deprecate this file relatively soon though. this is a pretty decently maintained package: https://github.com/zhirzh/flow-babel-webpack-plugin
I'd like to be able to include other changes made by that developer if possible. I left an issue about updating the NPM package. If it looks abandoned after enough time then we should look at bringing this in-house. I expect to deprecate this file relatively soon though.
but you're right, if need be it is definitely simple but you're right, if need be it is definitely simple
|
||||
var status = res.status;
|
||||
|
||||
if (status !== 0) {
|
||||
var errorCode = flowErrorCode(status);
|
||||
var errorDetails = res.stdout.toString() + res.stderr.toString();
|
||||
|
||||
store.error = new Error(store.options.formatter(errorCode, errorDetails));
|
||||
}
|
||||
|
||||
next();
|
||||
}
|
||||
|
||||
|
||||
function pushError(compilation) {
|
||||
if (store.error) {
|
||||
if (store.options.warn) {
|
||||
compilation.warnings.push(store.error);
|
||||
} else {
|
||||
compilation.errors.push(store.error);
|
||||
}
|
||||
|
||||
store.error = null;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
function FlowFlowPlugin(options) {
|
||||
store.options = merge(store.options, options);
|
||||
}
|
||||
|
||||
FlowFlowPlugin.prototype.apply = function(compiler) {
|
||||
compiler.plugin('run', checkFlowStatus);
|
||||
compiler.plugin('watch-run', checkFlowStatus);
|
||||
|
||||
compiler.plugin('compilation', pushError);
|
||||
};
|
||||
|
||||
module.exports = FlowFlowPlugin;
|
||||
|
|
@ -1,22 +1,60 @@
|
|||
|
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/
|
||||
// @flow
|
||||
|
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 types from "constants/action_types";
|
||||
import * as modalTypes from "constants/modal_types";
|
||||
|
||||
const { remote } = require("electron");
|
||||
|
||||
|
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/
|
||||
const application = remote.app;
|
||||
const win = remote.BrowserWindow.getFocusedWindow();
|
||||
|
||||
const reducers = {};
|
||||
const defaultState = {
|
||||
|
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/
|
||||
export type SnackBar = {
|
||||
|
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/
|
||||
message: string,
|
||||
|
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/
|
||||
linkText: string,
|
||||
|
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/
|
||||
linkTarget: string,
|
||||
|
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/
|
||||
isError: boolean,
|
||||
|
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/
|
||||
export type 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/
|
||||
isLoaded: boolean,
|
||||
|
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/
|
||||
modal: ?string,
|
||||
|
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/
|
||||
modalProps: 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/
|
||||
platform: string,
|
||||
|
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/
|
||||
upgradeSkipped: boolean,
|
||||
|
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/
|
||||
daemonVersionMatched: ?boolean,
|
||||
|
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/
|
||||
daemonReady: boolean,
|
||||
|
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: boolean,
|
||||
|
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/
|
||||
badgeNumber: number,
|
||||
|
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/
|
||||
volume: number,
|
||||
|
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: ?number,
|
||||
|
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/
|
||||
upgradeDownloading: ?boolean,
|
||||
|
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/
|
||||
upgradeDownloadComplete: ?boolean,
|
||||
|
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/
|
||||
checkUpgradeTimer: ?number,
|
||||
|
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/
|
||||
isUpgradeAvailable: ?boolean,
|
||||
|
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/
|
||||
isUpgradeSkipped: ?boolean,
|
||||
|
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/
|
||||
snackBar: ?SnackBar,
|
||||
|
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? 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/
|
||||
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/
|
||||
isLoaded: false,
|
||||
modal: null,
|
||||
modalProps: {},
|
||||
platform: process.platform,
|
||||
upgradeSkipped: sessionStorage.getItem("upgradeSkipped"),
|
||||
|
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/
|
||||
upgradeSkipped: sessionStorage.getItem("upgradeSkipped") === "true",
|
||||
|
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/
|
||||
daemonVersionMatched: null,
|
||||
daemonReady: false,
|
||||
|
Can you clarify this change? (And btw, we want to be killing this storage pattern) Can you clarify this change?
(And btw, we want to be killing this storage pattern)
`sessionStorage.getItem("upgradeSkipped")` returns the string: `"true"` so this is, essentailly, casting it to a boolean.
@liamcardenas but this changeset also changes this value from (If you just want to cast, I'd propose either a typical cast of @liamcardenas but this changeset also changes this value from `true` to `"true"`.
(If you just want to cast, I'd propose either a typical cast of `Boolean(foo)` or `!!foo`)
I think he's saying no matter how it was stored in Using the @liamcardenas is that right? I think he's saying no matter how it was stored in `sessionStorage` it was still being returned as `"true"`.
Using the `!!` operator or `Boolean` will still return `true` for `"false"` strings because strings are truthy.
@liamcardenas is that right?
that doesn't work, because This is the best way to get a boolean value that is recorded as a string. The alternative would be that doesn't work, because `Boolean('false')` and `!!'false'` evaluate to `true`
This is the best way to get a boolean value that is recorded as a string. The alternative would be `JSON.parse(foo)`, but I wouldn't want to be able to introduce arbitrary, non-boolean values.
Wow, sure enough, the Storage API changes the type! Absolute insanity! Wow, sure enough, the Storage API changes the type!
```
window.sessionStorage.setItem("foo", true);
undefined
window.sessionStorage.getItem("foo");
"true"
```
Absolute insanity!
I know, I wouldn't have caught this if flow didn't give me a type error for trying to input/expect booleans where it is supposed to be a string. That's the beauty of type checking, this could've led to some pretty nasty bugs. I know, I wouldn't have caught this if flow didn't give me a type error for trying to input/expect booleans where it is supposed to be a string.
That's the beauty of type checking, this could've led to some pretty nasty bugs.
|
||||
hasSignature: false,
|
||||
badgeNumber: 0,
|
||||
volume: 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/
|
||||
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/
|
||||
|
||||
|
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,
|
||||
|
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/
|
||||
upgradeDownloading: 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/
|
||||
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/
|
||||
checkUpgradeTimer: 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/
|
||||
isUpgradeAvailable: 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/
|
||||
isUpgradeSkipped: 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/
|
||||
snackBar: 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/
|
||||
};
|
||||
|
||||
reducers[types.DAEMON_READY] = function(state, action) {
|
||||
|
|
@ -61,7 +99,7 @@ reducers[types.UPGRADE_DOWNLOAD_STARTED] = function(state, action) {
|
|||
|
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/
|
||||
};
|
||||
|
||||
reducers[types.SKIP_UPGRADE] = function(state, action) {
|
||||
sessionStorage.setItem("upgradeSkipped", true);
|
||||
|
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/
|
||||
sessionStorage.setItem("upgradeSkipped", "true");
|
||||
|
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/
|
||||
|
||||
return Object.assign({}, state, {
|
||||
isUpgradeSkipped: true,
|
||||
|
|
@ -164,7 +202,7 @@ reducers[types.VOLUME_CHANGED] = function(state, action) {
|
|||
|
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/
|
||||
});
|
||||
};
|
||||
|
||||
export default function reducer(state = defaultState, action) {
|
||||
|
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/
|
||||
export default function reducer(state: AppState = defaultState, action: any) {
|
||||
|
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/
|
||||
const handler = reducers[action.type];
|
||||
if (handler) return handler(state, action);
|
||||
return state;
|
||||
|
|
|
|||
|
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/
|
||||
|
|
@ -63,6 +63,9 @@
|
|||
"eslint-plugin-import": "^2.2.0",
|
||||
"eslint-plugin-jsx-a11y": "^2.2.3",
|
||||
"eslint-plugin-react": "^6.7.1",
|
||||
"flow-babel-webpack-plugin": "^1.1.0",
|
||||
"flow-bin": "^0.59.0",
|
||||
"flow-typed": "^2.2.3",
|
||||
"husky": "^0.13.4",
|
||||
"i18n-extract": "^0.4.4",
|
||||
"json-loader": "^0.5.4",
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@ const webpack = require("webpack")
|
|||
const WebpackNotifierPlugin = require("webpack-notifier")
|
||||
const merge = require('webpack-merge');
|
||||
const common = require('./webpack.common.js');
|
||||
const FlowBabelWebpackPlugin = require('./flowtype-plugin');
|
||||
|
||||
|
||||
const PATHS = {
|
||||
|
|
@ -23,6 +24,9 @@ module.exports = merge(common, {
|
|||
}),
|
||||
new webpack.LoaderOptionsPlugin({
|
||||
debug: true
|
||||
}),
|
||||
new FlowBabelWebpackPlugin({
|
||||
warn: true
|
||||
})
|
||||
]
|
||||
});
|
||||
});
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ ajv-keywords@^1.0.0:
|
|||
version "1.5.1"
|
||||
resolved "https://registry.yarnpkg.com/ajv-keywords/-/ajv-keywords-1.5.1.tgz#314dd0a4b3368fad3dfcdc54ede6171b886daf3c"
|
||||
|
||||
ajv-keywords@^2.0.0:
|
||||
ajv-keywords@^2.0.0, ajv-keywords@^2.1.0:
|
||||
version "2.1.1"
|
||||
resolved "https://registry.yarnpkg.com/ajv-keywords/-/ajv-keywords-2.1.1.tgz#617997fc5f60576894c435f940d819e135b80762"
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ ajv@^4.7.0, ajv@^4.9.1:
|
|||
co "^4.6.0"
|
||||
json-stable-stringify "^1.0.1"
|
||||
|
||||
ajv@^5.0.0, ajv@^5.1.0, ajv@^5.1.5:
|
||||
ajv@^5.0.0, ajv@^5.1.5, ajv@^5.2.3:
|
||||
version "5.4.0"
|
||||
resolved "https://registry.yarnpkg.com/ajv/-/ajv-5.4.0.tgz#32d1cf08dbc80c432f426f12e10b2511f6b46474"
|
||||
dependencies:
|
||||
|
|
@ -276,11 +276,7 @@ aws-sign2@~0.6.0:
|
|||
version "0.6.0"
|
||||
resolved "https://registry.yarnpkg.com/aws-sign2/-/aws-sign2-0.6.0.tgz#14342dd38dbcc94d0e5b87d763cd63612c0e794f"
|
||||
|
||||
aws-sign2@~0.7.0:
|
||||
version "0.7.0"
|
||||
resolved "https://registry.yarnpkg.com/aws-sign2/-/aws-sign2-0.7.0.tgz#b46e890934a9591f2d2f6f86d7e6a9f1b3fe76a8"
|
||||
|
||||
aws4@^1.2.1, aws4@^1.6.0:
|
||||
aws4@^1.2.1:
|
||||
version "1.6.0"
|
||||
resolved "https://registry.yarnpkg.com/aws4/-/aws4-1.6.0.tgz#83ef5ca860b2b32e4a0deedee8c771b9db57471e"
|
||||
|
||||
|
|
@ -524,7 +520,7 @@ babel-plugin-syntax-exponentiation-operator@^6.8.0:
|
|||
version "6.13.0"
|
||||
resolved "https://registry.yarnpkg.com/babel-plugin-syntax-exponentiation-operator/-/babel-plugin-syntax-exponentiation-operator-6.13.0.tgz#9ee7e8337290da95288201a6a57f4170317830de"
|
||||
|
||||
babel-plugin-syntax-flow@^6.18.0:
|
||||
babel-plugin-syntax-flow@^6.18.0, babel-plugin-syntax-flow@^6.8.0:
|
||||
version "6.18.0"
|
||||
resolved "https://registry.yarnpkg.com/babel-plugin-syntax-flow/-/babel-plugin-syntax-flow-6.18.0.tgz#4c3ab20a2af26aa20cd25995c398c4eb70310c8d"
|
||||
|
||||
|
|
@ -751,6 +747,13 @@ babel-plugin-transform-exponentiation-operator@^6.24.1:
|
|||
babel-plugin-syntax-exponentiation-operator "^6.8.0"
|
||||
babel-runtime "^6.22.0"
|
||||
|
||||
babel-plugin-transform-flow-comments@^6.17.0:
|
||||
version "6.22.0"
|
||||
resolved "https://registry.yarnpkg.com/babel-plugin-transform-flow-comments/-/babel-plugin-transform-flow-comments-6.22.0.tgz#8d9491132f2b48abd0656f96c20f3bbd6fc17529"
|
||||
dependencies:
|
||||
babel-plugin-syntax-flow "^6.8.0"
|
||||
babel-runtime "^6.22.0"
|
||||
|
||||
babel-plugin-transform-flow-strip-types@^6.22.0:
|
||||
version "6.22.0"
|
||||
resolved "https://registry.yarnpkg.com/babel-plugin-transform-flow-strip-types/-/babel-plugin-transform-flow-strip-types-6.22.0.tgz#84cb672935d43714fdc32bce84568d87441cf7cf"
|
||||
|
|
@ -806,7 +809,7 @@ babel-plugin-transform-strict-mode@^6.24.1:
|
|||
babel-runtime "^6.22.0"
|
||||
babel-types "^6.24.1"
|
||||
|
||||
babel-polyfill@^6.20.0, babel-polyfill@^6.26.0:
|
||||
babel-polyfill@^6.20.0, babel-polyfill@^6.23.0, babel-polyfill@^6.26.0:
|
||||
version "6.26.0"
|
||||
resolved "https://registry.yarnpkg.com/babel-polyfill/-/babel-polyfill-6.26.0.tgz#379937abc67d7895970adc621f284cd966cf2153"
|
||||
dependencies:
|
||||
|
|
@ -981,6 +984,13 @@ binary-search@^1.2.0:
|
|||
version "1.3.2"
|
||||
resolved "https://registry.yarnpkg.com/binary-search/-/binary-search-1.3.2.tgz#88c9b7bd2b7221d352da78ec887f5af2549e4de2"
|
||||
|
||||
"binary@>= 0.3.0 < 1":
|
||||
version "0.3.0"
|
||||
resolved "https://registry.yarnpkg.com/binary/-/binary-0.3.0.tgz#9f60553bc5ce8c3386f3b553cff47462adecaa79"
|
||||
dependencies:
|
||||
buffers "~0.1.1"
|
||||
chainsaw "~0.1.0"
|
||||
|
||||
block-stream@*:
|
||||
version "0.0.9"
|
||||
resolved "https://registry.yarnpkg.com/block-stream/-/block-stream-0.0.9.tgz#13ebfe778a03205cfe03751481ebb4b3300c126a"
|
||||
|
|
@ -1023,18 +1033,6 @@ boom@2.x.x:
|
|||
dependencies:
|
||||
hoek "2.x.x"
|
||||
|
||||
boom@4.x.x:
|
||||
version "4.3.1"
|
||||
resolved "https://registry.yarnpkg.com/boom/-/boom-4.3.1.tgz#4f8a3005cb4a7e3889f749030fd25b96e01d2e31"
|
||||
dependencies:
|
||||
hoek "4.x.x"
|
||||
|
||||
boom@5.x.x:
|
||||
version "5.2.0"
|
||||
resolved "https://registry.yarnpkg.com/boom/-/boom-5.2.0.tgz#5dd9da6ee3a5f302077436290cb717d3f4a54e02"
|
||||
dependencies:
|
||||
hoek "4.x.x"
|
||||
|
||||
brace-expansion@^1.1.7:
|
||||
version "1.1.8"
|
||||
resolved "https://registry.yarnpkg.com/brace-expansion/-/brace-expansion-1.1.8.tgz#c07b211c7c952ec1f8efd51a77ef0d1d3990a292"
|
||||
|
|
@ -1141,6 +1139,10 @@ buffer@^4.3.0, buffer@^4.9.0:
|
|||
ieee754 "^1.1.4"
|
||||
isarray "^1.0.0"
|
||||
|
||||
buffers@~0.1.1:
|
||||
version "0.1.1"
|
||||
resolved "https://registry.yarnpkg.com/buffers/-/buffers-0.1.1.tgz#b24579c3bed4d6d396aeee6d9a8ae7f5482ab7bb"
|
||||
|
||||
builtin-modules@^1.0.0, builtin-modules@^1.1.1:
|
||||
version "1.1.1"
|
||||
resolved "https://registry.yarnpkg.com/builtin-modules/-/builtin-modules-1.1.1.tgz#270f076c5a72c02f5b65a47df94c5fe3a278892f"
|
||||
|
|
@ -1221,6 +1223,12 @@ center-align@^0.1.1:
|
|||
align-text "^0.1.3"
|
||||
lazy-cache "^1.0.3"
|
||||
|
||||
chainsaw@~0.1.0:
|
||||
version "0.1.0"
|
||||
resolved "https://registry.yarnpkg.com/chainsaw/-/chainsaw-0.1.0.tgz#5eab50b28afe58074d0d58291388828b5e5fbc98"
|
||||
dependencies:
|
||||
traverse ">=0.3.0 <0.4"
|
||||
|
||||
chalk@^1.0.0, chalk@^1.1.1, chalk@^1.1.3:
|
||||
version "1.1.3"
|
||||
resolved "https://registry.yarnpkg.com/chalk/-/chalk-1.1.3.tgz#a8115c55e4a702fe4d150abd3872822a7e09fc98"
|
||||
|
|
@ -1231,7 +1239,7 @@ chalk@^1.0.0, chalk@^1.1.1, chalk@^1.1.3:
|
|||
strip-ansi "^3.0.0"
|
||||
supports-color "^2.0.0"
|
||||
|
||||
chalk@^2.3.0:
|
||||
chalk@^2.1.0, chalk@^2.3.0:
|
||||
version "2.3.0"
|
||||
resolved "https://registry.yarnpkg.com/chalk/-/chalk-2.3.0.tgz#b5ea48efc9c1793dccc9b4767c93914d3f2d52ba"
|
||||
dependencies:
|
||||
|
|
@ -1239,6 +1247,10 @@ chalk@^2.3.0:
|
|||
escape-string-regexp "^1.0.5"
|
||||
supports-color "^4.0.0"
|
||||
|
||||
charenc@~0.0.1:
|
||||
version "0.0.2"
|
||||
resolved "https://registry.yarnpkg.com/charenc/-/charenc-0.0.2.tgz#c0a1d2f3a7092e03774bfa83f14c0fc5790a8667"
|
||||
|
||||
chokidar@^1.0.0, chokidar@^1.6.0, chokidar@^1.6.1, chokidar@^1.7.0:
|
||||
version "1.7.0"
|
||||
resolved "https://registry.yarnpkg.com/chokidar/-/chokidar-1.7.0.tgz#798e689778151c8076b4b360e5edd28cda2bb468"
|
||||
|
|
@ -1599,18 +1611,16 @@ cross-spawn@^5.0.1:
|
|||
shebang-command "^1.2.0"
|
||||
which "^1.2.9"
|
||||
|
||||
crypt@~0.0.1:
|
||||
version "0.0.2"
|
||||
resolved "https://registry.yarnpkg.com/crypt/-/crypt-0.0.2.tgz#88d7ff7ec0dfb86f713dc87bbb42d044d3e6c41b"
|
||||
|
||||
cryptiles@2.x.x:
|
||||
version "2.0.5"
|
||||
resolved "https://registry.yarnpkg.com/cryptiles/-/cryptiles-2.0.5.tgz#3bdfecdc608147c1c67202fa291e7dca59eaa3b8"
|
||||
dependencies:
|
||||
boom "2.x.x"
|
||||
|
||||
cryptiles@3.x.x:
|
||||
version "3.1.2"
|
||||
resolved "https://registry.yarnpkg.com/cryptiles/-/cryptiles-3.1.2.tgz#a89fbb220f5ce25ec56e8c4aa8a4fd7b5b0d29fe"
|
||||
dependencies:
|
||||
boom "5.x.x"
|
||||
|
||||
crypto-browserify@3.3.0:
|
||||
version "3.3.0"
|
||||
resolved "https://registry.yarnpkg.com/crypto-browserify/-/crypto-browserify-3.3.0.tgz#b9fc75bb4a0ed61dcf1cd5dae96eb30c9c3e506c"
|
||||
|
|
@ -1761,6 +1771,12 @@ decamelize@^1.0.0, decamelize@^1.1.1, decamelize@^1.1.2:
|
|||
version "1.2.0"
|
||||
resolved "https://registry.yarnpkg.com/decamelize/-/decamelize-1.2.0.tgz#f6534d15148269b20352e7bee26f501f9a191290"
|
||||
|
||||
decompress-response@^3.2.0:
|
||||
version "3.3.0"
|
||||
resolved "https://registry.yarnpkg.com/decompress-response/-/decompress-response-3.3.0.tgz#80a4dd323748384bfa248083622aedec982adff3"
|
||||
dependencies:
|
||||
mimic-response "^1.0.0"
|
||||
|
||||
deep-diff@^0.3.5:
|
||||
version "0.3.8"
|
||||
resolved "https://registry.yarnpkg.com/deep-diff/-/deep-diff-0.3.8.tgz#c01de63efb0eec9798801d40c7e0dae25b582c84"
|
||||
|
|
@ -1898,6 +1914,10 @@ domain-browser@^1.1.1:
|
|||
version "1.1.7"
|
||||
resolved "https://registry.yarnpkg.com/domain-browser/-/domain-browser-1.1.7.tgz#867aa4b093faa05f1de08c06f4d7b21fdf8698bc"
|
||||
|
||||
duplexer3@^0.1.4:
|
||||
version "0.1.4"
|
||||
resolved "https://registry.yarnpkg.com/duplexer3/-/duplexer3-0.1.4.tgz#ee01dd1cac0ed3cbc7fdbea37dc0a8f1ce002ce2"
|
||||
|
||||
ecc-jsbn@~0.1.1:
|
||||
version "0.1.1"
|
||||
resolved "https://registry.yarnpkg.com/ecc-jsbn/-/ecc-jsbn-0.1.1.tgz#0fc73a9ed5f0d53c38193398523ef7e543777505"
|
||||
|
|
@ -2367,7 +2387,7 @@ express@^4.13.3:
|
|||
utils-merge "1.0.1"
|
||||
vary "~1.1.2"
|
||||
|
||||
extend@~3.0.0, extend@~3.0.1:
|
||||
extend@~3.0.0:
|
||||
version "3.0.1"
|
||||
resolved "https://registry.yarnpkg.com/extend/-/extend-3.0.1.tgz#a755ea7bc1adfcc5a31ce7e762dbaadc5e636444"
|
||||
|
||||
|
|
@ -2526,6 +2546,39 @@ flatten@^1.0.2:
|
|||
version "1.0.2"
|
||||
resolved "https://registry.yarnpkg.com/flatten/-/flatten-1.0.2.tgz#dae46a9d78fbe25292258cc1e780a41d95c03782"
|
||||
|
||||
flow-babel-webpack-plugin@^1.1.0:
|
||||
version "1.1.0"
|
||||
resolved "https://registry.yarnpkg.com/flow-babel-webpack-plugin/-/flow-babel-webpack-plugin-1.1.0.tgz#a8dfa7430fc88d18d7d28acc96edf0e2a2329510"
|
||||
dependencies:
|
||||
babel-plugin-transform-flow-comments "^6.17.0"
|
||||
flow-bin ">=0.44.2 <1"
|
||||
lodash.merge "^4.6.0"
|
||||
|
||||
"flow-bin@>=0.44.2 <1", flow-bin@^0.59.0:
|
||||
version "0.59.0"
|
||||
resolved "https://registry.yarnpkg.com/flow-bin/-/flow-bin-0.59.0.tgz#8c151ee7f09f1deed9bf0b9d1f2e8ab9d470f1bb"
|
||||
|
||||
flow-typed@^2.2.3:
|
||||
version "2.2.3"
|
||||
resolved "https://registry.yarnpkg.com/flow-typed/-/flow-typed-2.2.3.tgz#e7a35915a0f4cfcf8068c1ce291b5c99e6b89efa"
|
||||
dependencies:
|
||||
babel-polyfill "^6.23.0"
|
||||
colors "^1.1.2"
|
||||
fs-extra "^4.0.0"
|
||||
github "0.2.4"
|
||||
glob "^7.1.2"
|
||||
got "^7.1.0"
|
||||
md5 "^2.1.0"
|
||||
mkdirp "^0.5.1"
|
||||
request "^2.81.0"
|
||||
rimraf "^2.6.1"
|
||||
semver "^5.1.0"
|
||||
table "^4.0.1"
|
||||
through "^2.3.8"
|
||||
unzip "^0.1.11"
|
||||
which "^1.2.14"
|
||||
yargs "^4.2.0"
|
||||
|
||||
for-in@^1.0.1:
|
||||
version "1.0.2"
|
||||
resolved "https://registry.yarnpkg.com/for-in/-/for-in-1.0.2.tgz#81068d295a8142ec0ac726c6e2200c30fb6d5e80"
|
||||
|
|
@ -2552,14 +2605,6 @@ form-data@~2.1.1:
|
|||
combined-stream "^1.0.5"
|
||||
mime-types "^2.1.12"
|
||||
|
||||
form-data@~2.3.1:
|
||||
version "2.3.1"
|
||||
resolved "https://registry.yarnpkg.com/form-data/-/form-data-2.3.1.tgz#6fb94fbd71885306d73d15cc497fe4cc4ecd44bf"
|
||||
dependencies:
|
||||
asynckit "^0.4.0"
|
||||
combined-stream "^1.0.5"
|
||||
mime-types "^2.1.12"
|
||||
|
||||
forwarded@~0.1.2:
|
||||
version "0.1.2"
|
||||
resolved "https://registry.yarnpkg.com/forwarded/-/forwarded-0.1.2.tgz#98c23dab1175657b8c0573e8ceccd91b0ff18c84"
|
||||
|
|
@ -2583,6 +2628,14 @@ fs-extra@^3.0.1:
|
|||
jsonfile "^3.0.0"
|
||||
universalify "^0.1.0"
|
||||
|
||||
fs-extra@^4.0.0:
|
||||
version "4.0.2"
|
||||
resolved "https://registry.yarnpkg.com/fs-extra/-/fs-extra-4.0.2.tgz#f91704c53d1b461f893452b0c307d9997647ab6b"
|
||||
dependencies:
|
||||
graceful-fs "^4.1.2"
|
||||
jsonfile "^4.0.0"
|
||||
universalify "^0.1.0"
|
||||
|
||||
fs-readdir-recursive@^1.0.0:
|
||||
version "1.1.0"
|
||||
resolved "https://registry.yarnpkg.com/fs-readdir-recursive/-/fs-readdir-recursive-1.1.0.tgz#e32fc030a2ccee44a6b5371308da54be0b397d27"
|
||||
|
|
@ -2606,6 +2659,15 @@ fstream-ignore@^1.0.5:
|
|||
inherits "2"
|
||||
minimatch "^3.0.0"
|
||||
|
||||
"fstream@>= 0.1.30 < 1":
|
||||
version "0.1.31"
|
||||
resolved "https://registry.yarnpkg.com/fstream/-/fstream-0.1.31.tgz#7337f058fbbbbefa8c9f561a28cab0849202c988"
|
||||
dependencies:
|
||||
graceful-fs "~3.0.2"
|
||||
inherits "~2.0.0"
|
||||
mkdirp "0.5"
|
||||
rimraf "2"
|
||||
|
||||
fstream@^1.0.0, fstream@^1.0.10, fstream@^1.0.2:
|
||||
version "1.0.11"
|
||||
resolved "https://registry.yarnpkg.com/fstream/-/fstream-1.0.11.tgz#5c1fb1f117477114f0632a0eb4b71b3cb0fd3171"
|
||||
|
|
@ -2673,6 +2735,12 @@ gettext-parser@^1.2.0:
|
|||
encoding "^0.1.12"
|
||||
safe-buffer "^5.1.1"
|
||||
|
||||
github@0.2.4:
|
||||
version "0.2.4"
|
||||
resolved "https://registry.yarnpkg.com/github/-/github-0.2.4.tgz#24fa7f0e13fa11b946af91134c51982a91ce538b"
|
||||
dependencies:
|
||||
mime "^1.2.11"
|
||||
|
||||
glob-base@^0.3.0:
|
||||
version "0.3.0"
|
||||
resolved "https://registry.yarnpkg.com/glob-base/-/glob-base-0.3.0.tgz#dbb164f6221b1c0b1ccf82aea328b497df0ea3c4"
|
||||
|
|
@ -2750,10 +2818,35 @@ globule@^1.0.0:
|
|||
lodash "~4.17.4"
|
||||
minimatch "~3.0.2"
|
||||
|
||||
got@^7.1.0:
|
||||
version "7.1.0"
|
||||
resolved "https://registry.yarnpkg.com/got/-/got-7.1.0.tgz#05450fd84094e6bbea56f451a43a9c289166385a"
|
||||
dependencies:
|
||||
decompress-response "^3.2.0"
|
||||
duplexer3 "^0.1.4"
|
||||
get-stream "^3.0.0"
|
||||
is-plain-obj "^1.1.0"
|
||||
is-retry-allowed "^1.0.0"
|
||||
is-stream "^1.0.0"
|
||||
isurl "^1.0.0-alpha5"
|
||||
lowercase-keys "^1.0.0"
|
||||
p-cancelable "^0.3.0"
|
||||
p-timeout "^1.1.1"
|
||||
safe-buffer "^5.0.1"
|
||||
timed-out "^4.0.0"
|
||||
url-parse-lax "^1.0.0"
|
||||
url-to-options "^1.0.1"
|
||||
|
||||
graceful-fs@^4.1.2, graceful-fs@^4.1.4, graceful-fs@^4.1.6:
|
||||
version "4.1.11"
|
||||
resolved "https://registry.yarnpkg.com/graceful-fs/-/graceful-fs-4.1.11.tgz#0e8bdfe4d1ddb8854d64e04ea7c00e2a026e5658"
|
||||
|
||||
graceful-fs@~3.0.2:
|
||||
version "3.0.11"
|
||||
resolved "https://registry.yarnpkg.com/graceful-fs/-/graceful-fs-3.0.11.tgz#7613c778a1afea62f25c630a086d7f3acbbdd818"
|
||||
dependencies:
|
||||
natives "^1.1.0"
|
||||
|
||||
growly@^1.2.0:
|
||||
version "1.3.0"
|
||||
resolved "https://registry.yarnpkg.com/growly/-/growly-1.3.0.tgz#f10748cbe76af964b7c96c93c6bcc28af120c081"
|
||||
|
|
@ -2766,10 +2859,6 @@ har-schema@^1.0.5:
|
|||
version "1.0.5"
|
||||
resolved "https://registry.yarnpkg.com/har-schema/-/har-schema-1.0.5.tgz#d263135f43307c02c602afc8fe95970c0151369e"
|
||||
|
||||
har-schema@^2.0.0:
|
||||
version "2.0.0"
|
||||
resolved "https://registry.yarnpkg.com/har-schema/-/har-schema-2.0.0.tgz#a94c2224ebcac04782a0d9035521f24735b7ec92"
|
||||
|
||||
har-validator@~2.0.6:
|
||||
version "2.0.6"
|
||||
resolved "https://registry.yarnpkg.com/har-validator/-/har-validator-2.0.6.tgz#cdcbc08188265ad119b6a5a7c8ab70eecfb5d27d"
|
||||
|
|
@ -2786,13 +2875,6 @@ har-validator@~4.2.1:
|
|||
ajv "^4.9.1"
|
||||
har-schema "^1.0.5"
|
||||
|
||||
har-validator@~5.0.3:
|
||||
version "5.0.3"
|
||||
resolved "https://registry.yarnpkg.com/har-validator/-/har-validator-5.0.3.tgz#ba402c266194f15956ef15e0fcf242993f6a7dfd"
|
||||
dependencies:
|
||||
ajv "^5.1.0"
|
||||
har-schema "^2.0.0"
|
||||
|
||||
has-ansi@^2.0.0:
|
||||
version "2.0.0"
|
||||
resolved "https://registry.yarnpkg.com/has-ansi/-/has-ansi-2.0.0.tgz#34f5049ce1ecdf2b0649af3ef24e45ed35416d91"
|
||||
|
|
@ -2807,6 +2889,16 @@ has-flag@^2.0.0:
|
|||
version "2.0.0"
|
||||
resolved "https://registry.yarnpkg.com/has-flag/-/has-flag-2.0.0.tgz#e8207af1cc7b30d446cc70b734b5e8be18f88d51"
|
||||
|
||||
has-symbol-support-x@^1.4.1:
|
||||
version "1.4.1"
|
||||
resolved "https://registry.yarnpkg.com/has-symbol-support-x/-/has-symbol-support-x-1.4.1.tgz#66ec2e377e0c7d7ccedb07a3a84d77510ff1bc4c"
|
||||
|
||||
has-to-string-tag-x@^1.2.0:
|
||||
version "1.4.1"
|
||||
resolved "https://registry.yarnpkg.com/has-to-string-tag-x/-/has-to-string-tag-x-1.4.1.tgz#a045ab383d7b4b2012a00148ab0aa5f290044d4d"
|
||||
dependencies:
|
||||
has-symbol-support-x "^1.4.1"
|
||||
|
||||
has-unicode@^2.0.0:
|
||||
version "2.0.1"
|
||||
resolved "https://registry.yarnpkg.com/has-unicode/-/has-unicode-2.0.1.tgz#e0e6fe6a28cf51138855e086d1691e771de2a8b9"
|
||||
|
|
@ -2846,15 +2938,6 @@ hawk@3.1.3, hawk@~3.1.3:
|
|||
hoek "2.x.x"
|
||||
sntp "1.x.x"
|
||||
|
||||
hawk@~6.0.2:
|
||||
version "6.0.2"
|
||||
resolved "https://registry.yarnpkg.com/hawk/-/hawk-6.0.2.tgz#af4d914eb065f9b5ce4d9d11c1cb2126eecc3038"
|
||||
dependencies:
|
||||
boom "4.x.x"
|
||||
cryptiles "3.x.x"
|
||||
hoek "4.x.x"
|
||||
sntp "2.x.x"
|
||||
|
||||
hmac-drbg@^1.0.0:
|
||||
version "1.0.1"
|
||||
resolved "https://registry.yarnpkg.com/hmac-drbg/-/hmac-drbg-1.0.1.tgz#d2745701025a6c775a6c545793ed502fc0c649a1"
|
||||
|
|
@ -2867,10 +2950,6 @@ hoek@2.x.x:
|
|||
version "2.16.3"
|
||||
resolved "https://registry.yarnpkg.com/hoek/-/hoek-2.16.3.tgz#20bb7403d3cea398e91dc4710a8ff1b8274a25ed"
|
||||
|
||||
hoek@4.x.x:
|
||||
version "4.2.0"
|
||||
resolved "https://registry.yarnpkg.com/hoek/-/hoek-4.2.0.tgz#72d9d0754f7fe25ca2d01ad8f8f9a9449a89526d"
|
||||
|
||||
hoist-non-react-statics@^2.2.1:
|
||||
version "2.3.1"
|
||||
resolved "https://registry.yarnpkg.com/hoist-non-react-statics/-/hoist-non-react-statics-2.3.1.tgz#343db84c6018c650778898240135a1420ee22ce0"
|
||||
|
|
@ -2944,14 +3023,6 @@ http-signature@~1.1.0:
|
|||
jsprim "^1.2.2"
|
||||
sshpk "^1.7.0"
|
||||
|
||||
http-signature@~1.2.0:
|
||||
version "1.2.0"
|
||||
resolved "https://registry.yarnpkg.com/http-signature/-/http-signature-1.2.0.tgz#9aecd925114772f3d95b65a60abb8f7c18fbace1"
|
||||
dependencies:
|
||||
assert-plus "^1.0.0"
|
||||
jsprim "^1.2.2"
|
||||
sshpk "^1.7.0"
|
||||
|
||||
https-browserify@0.0.1:
|
||||
version "0.0.1"
|
||||
resolved "https://registry.yarnpkg.com/https-browserify/-/https-browserify-0.0.1.tgz#3f91365cabe60b77ed0ebba24b454e3e09d95a82"
|
||||
|
|
@ -3131,7 +3202,7 @@ is-binary-path@^1.0.0:
|
|||
dependencies:
|
||||
binary-extensions "^1.0.0"
|
||||
|
||||
is-buffer@^1.1.5:
|
||||
is-buffer@^1.1.5, is-buffer@~1.1.1:
|
||||
version "1.1.6"
|
||||
resolved "https://registry.yarnpkg.com/is-buffer/-/is-buffer-1.1.6.tgz#efaa2ea9daa0d7ab2ea13a97b2b8ad51fefbe8be"
|
||||
|
||||
|
|
@ -3226,6 +3297,10 @@ is-number@^3.0.0:
|
|||
dependencies:
|
||||
kind-of "^3.0.2"
|
||||
|
||||
is-object@^1.0.1:
|
||||
version "1.0.1"
|
||||
resolved "https://registry.yarnpkg.com/is-object/-/is-object-1.0.1.tgz#8952688c5ec2ffd6b03ecc85e769e02903083470"
|
||||
|
||||
is-path-cwd@^1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/is-path-cwd/-/is-path-cwd-1.0.0.tgz#d225ec23132e89edd38fda767472e62e65f1106d"
|
||||
|
|
@ -3242,7 +3317,7 @@ is-path-inside@^1.0.0:
|
|||
dependencies:
|
||||
path-is-inside "^1.0.1"
|
||||
|
||||
is-plain-obj@^1.0.0:
|
||||
is-plain-obj@^1.0.0, is-plain-obj@^1.1.0:
|
||||
version "1.1.0"
|
||||
resolved "https://registry.yarnpkg.com/is-plain-obj/-/is-plain-obj-1.1.0.tgz#71a50c8429dfca773c92a390a4a03b39fcd51d3e"
|
||||
|
||||
|
|
@ -3274,7 +3349,11 @@ is-resolvable@^1.0.0:
|
|||
dependencies:
|
||||
tryit "^1.0.1"
|
||||
|
||||
is-stream@^1.0.1, is-stream@^1.1.0:
|
||||
is-retry-allowed@^1.0.0:
|
||||
version "1.1.0"
|
||||
resolved "https://registry.yarnpkg.com/is-retry-allowed/-/is-retry-allowed-1.1.0.tgz#11a060568b67339444033d0125a61a20d564fb34"
|
||||
|
||||
is-stream@^1.0.0, is-stream@^1.0.1, is-stream@^1.1.0:
|
||||
version "1.1.0"
|
||||
resolved "https://registry.yarnpkg.com/is-stream/-/is-stream-1.1.0.tgz#12d4a3dd4e68e0b79ceb8dbc84173ae80d91ca44"
|
||||
|
||||
|
|
@ -3329,6 +3408,13 @@ isstream@~0.1.2:
|
|||
version "0.1.2"
|
||||
resolved "https://registry.yarnpkg.com/isstream/-/isstream-0.1.2.tgz#47e63f7af55afa6f92e1500e690eb8b8529c099a"
|
||||
|
||||
isurl@^1.0.0-alpha5:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/isurl/-/isurl-1.0.0.tgz#b27f4f49f3cdaa3ea44a0a5b7f3462e6edc39d67"
|
||||
dependencies:
|
||||
has-to-string-tag-x "^1.2.0"
|
||||
is-object "^1.0.1"
|
||||
|
||||
js-base64@^2.1.8, js-base64@^2.1.9:
|
||||
version "2.3.2"
|
||||
resolved "https://registry.yarnpkg.com/js-base64/-/js-base64-2.3.2.tgz#a79a923666372b580f8e27f51845c6f7e8fbfbaf"
|
||||
|
|
@ -3403,6 +3489,12 @@ jsonfile@^3.0.0:
|
|||
optionalDependencies:
|
||||
graceful-fs "^4.1.6"
|
||||
|
||||
jsonfile@^4.0.0:
|
||||
version "4.0.0"
|
||||
resolved "https://registry.yarnpkg.com/jsonfile/-/jsonfile-4.0.0.tgz#8771aae0799b64076b76640fca058f9c10e33ecb"
|
||||
optionalDependencies:
|
||||
graceful-fs "^4.1.6"
|
||||
|
||||
jsonify@~0.0.0:
|
||||
version "0.0.0"
|
||||
resolved "https://registry.yarnpkg.com/jsonify/-/jsonify-0.0.0.tgz#2c74b6ee41d93ca51b7b5aaee8f503631d252a73"
|
||||
|
|
@ -3651,7 +3743,7 @@ lodash._getnative@^3.0.0:
|
|||
version "3.9.1"
|
||||
resolved "https://registry.yarnpkg.com/lodash._getnative/-/lodash._getnative-3.9.1.tgz#570bc7dede46d61cdcde687d65d3eecbaa3aaff5"
|
||||
|
||||
lodash.assign@^4.2.0:
|
||||
lodash.assign@^4.0.3, lodash.assign@^4.0.6, lodash.assign@^4.2.0:
|
||||
version "4.2.0"
|
||||
resolved "https://registry.yarnpkg.com/lodash.assign/-/lodash.assign-4.2.0.tgz#0d99f3ccd7a6d261d19bdaeb9245005d285808e7"
|
||||
|
||||
|
|
@ -3714,6 +3806,10 @@ lodash.memoize@^4.1.2:
|
|||
version "4.1.2"
|
||||
resolved "https://registry.yarnpkg.com/lodash.memoize/-/lodash.memoize-4.1.2.tgz#bcc6c49a42a2840ed997f323eada5ecd182e0bfe"
|
||||
|
||||
lodash.merge@^4.6.0:
|
||||
version "4.6.0"
|
||||
resolved "https://registry.yarnpkg.com/lodash.merge/-/lodash.merge-4.6.0.tgz#69884ba144ac33fe699737a6086deffadd0f89c5"
|
||||
|
||||
lodash.mergewith@^4.6.0:
|
||||
version "4.6.0"
|
||||
resolved "https://registry.yarnpkg.com/lodash.mergewith/-/lodash.mergewith-4.6.0.tgz#150cf0a16791f5903b8891eab154609274bdea55"
|
||||
|
|
@ -3776,6 +3872,10 @@ loud-rejection@^1.0.0:
|
|||
currently-unhandled "^0.4.1"
|
||||
signal-exit "^3.0.0"
|
||||
|
||||
lowercase-keys@^1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/lowercase-keys/-/lowercase-keys-1.0.0.tgz#4e3366b39e7f5457e35f1324bdf6f88d0bfc7306"
|
||||
|
||||
lru-cache@^4.0.1:
|
||||
version "4.1.1"
|
||||
resolved "https://registry.yarnpkg.com/lru-cache/-/lru-cache-4.1.1.tgz#622e32e82488b49279114a4f9ecf45e7cd6bba55"
|
||||
|
|
@ -3815,6 +3915,13 @@ marked@*, marked@^0.3.6:
|
|||
version "0.3.6"
|
||||
resolved "https://registry.yarnpkg.com/marked/-/marked-0.3.6.tgz#b2c6c618fccece4ef86c4fc6cb8a7cbf5aeda8d7"
|
||||
|
||||
"match-stream@>= 0.0.2 < 1":
|
||||
version "0.0.2"
|
||||
resolved "https://registry.yarnpkg.com/match-stream/-/match-stream-0.0.2.tgz#99eb050093b34dffade421b9ac0b410a9cfa17cf"
|
||||
dependencies:
|
||||
buffers "~0.1.1"
|
||||
readable-stream "~1.0.0"
|
||||
|
||||
math-expression-evaluator@^1.2.14:
|
||||
version "1.2.17"
|
||||
resolved "https://registry.yarnpkg.com/math-expression-evaluator/-/math-expression-evaluator-1.2.17.tgz#de819fdbcd84dccd8fae59c6aeb79615b9d266ac"
|
||||
|
|
@ -3826,6 +3933,14 @@ md5.js@^1.3.4:
|
|||
hash-base "^3.0.0"
|
||||
inherits "^2.0.1"
|
||||
|
||||
md5@^2.1.0:
|
||||
version "2.2.1"
|
||||
resolved "https://registry.yarnpkg.com/md5/-/md5-2.2.1.tgz#53ab38d5fe3c8891ba465329ea23fac0540126f9"
|
||||
dependencies:
|
||||
charenc "~0.0.1"
|
||||
crypt "~0.0.1"
|
||||
is-buffer "~1.1.1"
|
||||
|
||||
"mdurl@~ 1.0.1":
|
||||
version "1.0.1"
|
||||
resolved "https://registry.yarnpkg.com/mdurl/-/mdurl-1.0.1.tgz#fe85b2ec75a59037f2adfec100fd6c601761152e"
|
||||
|
|
@ -3914,11 +4029,7 @@ miller-rabin@^4.0.0:
|
|||
bn.js "^4.0.0"
|
||||
brorand "^1.0.1"
|
||||
|
||||
"mime-db@>= 1.30.0 < 2":
|
||||
version "1.31.0"
|
||||
resolved "https://registry.yarnpkg.com/mime-db/-/mime-db-1.31.0.tgz#a49cd8f3ebf3ed1a482b60561d9105ad40ca74cb"
|
||||
|
||||
mime-db@~1.30.0:
|
||||
"mime-db@>= 1.30.0 < 2", mime-db@~1.30.0:
|
||||
version "1.30.0"
|
||||
resolved "https://registry.yarnpkg.com/mime-db/-/mime-db-1.30.0.tgz#74c643da2dd9d6a45399963465b26d5ca7d71f01"
|
||||
|
||||
|
|
@ -3928,7 +4039,7 @@ mime-types@^2.1.12, mime-types@~2.1.15, mime-types@~2.1.16, mime-types@~2.1.17,
|
|||
dependencies:
|
||||
mime-db "~1.30.0"
|
||||
|
||||
mime@1.4.1, mime@^1.3.4:
|
||||
mime@1.4.1, mime@^1.2.11, mime@^1.3.4:
|
||||
version "1.4.1"
|
||||
resolved "https://registry.yarnpkg.com/mime/-/mime-1.4.1.tgz#121f9ebc49e3766f311a76e1fa1c8003c4b03aa6"
|
||||
|
||||
|
|
@ -3936,6 +4047,10 @@ mimic-fn@^1.0.0:
|
|||
version "1.1.0"
|
||||
resolved "https://registry.yarnpkg.com/mimic-fn/-/mimic-fn-1.1.0.tgz#e667783d92e89dbd342818b5230b9d62a672ad18"
|
||||
|
||||
mimic-response@^1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/mimic-response/-/mimic-response-1.0.0.tgz#df3d3652a73fded6b9b0b24146e6fd052353458e"
|
||||
|
||||
minimalistic-assert@^1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/minimalistic-assert/-/minimalistic-assert-1.0.0.tgz#702be2dda6b37f4836bcb3f5db56641b64a1d3d3"
|
||||
|
|
@ -3950,7 +4065,7 @@ minimalistic-crypto-utils@^1.0.0, minimalistic-crypto-utils@^1.0.1:
|
|||
dependencies:
|
||||
brace-expansion "^1.1.7"
|
||||
|
||||
minimist@0.0.8:
|
||||
minimist@0.0.8, minimist@~0.0.1:
|
||||
version "0.0.8"
|
||||
resolved "https://registry.yarnpkg.com/minimist/-/minimist-0.0.8.tgz#857fcabfc3397d2625b8228262e86aa7a011b05d"
|
||||
|
||||
|
|
@ -3958,11 +4073,7 @@ minimist@^1.1.1, minimist@^1.1.3, minimist@^1.2.0:
|
|||
version "1.2.0"
|
||||
resolved "https://registry.yarnpkg.com/minimist/-/minimist-1.2.0.tgz#a35008b20f41383eec1fb914f4cd5df79a264284"
|
||||
|
||||
minimist@~0.0.1:
|
||||
version "0.0.10"
|
||||
resolved "https://registry.yarnpkg.com/minimist/-/minimist-0.0.10.tgz#de3f98543dbf96082be48ad1a0c7cda836301dcf"
|
||||
|
||||
mkdirp@0.5.1, mkdirp@0.5.x, "mkdirp@>=0.5 0", mkdirp@^0.5.0, mkdirp@^0.5.1, mkdirp@~0.5.0, mkdirp@~0.5.1:
|
||||
mkdirp@0.5, mkdirp@0.5.1, mkdirp@0.5.x, "mkdirp@>=0.5 0", mkdirp@^0.5.0, mkdirp@^0.5.1, mkdirp@~0.5.0, mkdirp@~0.5.1:
|
||||
version "0.5.1"
|
||||
resolved "https://registry.yarnpkg.com/mkdirp/-/mkdirp-0.5.1.tgz#30057438eac6cf7f8c4767f38648d6697d75c903"
|
||||
dependencies:
|
||||
|
|
@ -4013,6 +4124,10 @@ nan@^2.3.0, nan@^2.3.2:
|
|||
version "2.8.0"
|
||||
resolved "https://registry.yarnpkg.com/nan/-/nan-2.8.0.tgz#ed715f3fe9de02b57a5e6252d90a96675e1f085a"
|
||||
|
||||
natives@^1.1.0:
|
||||
version "1.1.0"
|
||||
resolved "https://registry.yarnpkg.com/natives/-/natives-1.1.0.tgz#e9ff841418a6b2ec7a495e939984f78f163e6e31"
|
||||
|
||||
natural-compare@^1.4.0:
|
||||
version "1.4.0"
|
||||
resolved "https://registry.yarnpkg.com/natural-compare/-/natural-compare-1.4.0.tgz#4abebfeed7541f2c27acfb29bdbbd15c8d5ba4f7"
|
||||
|
|
@ -4260,7 +4375,7 @@ number-is-nan@^1.0.0:
|
|||
version "1.0.1"
|
||||
resolved "https://registry.yarnpkg.com/number-is-nan/-/number-is-nan-1.0.1.tgz#097b602b53422a522c1afb8790318336941a011d"
|
||||
|
||||
oauth-sign@~0.8.1, oauth-sign@~0.8.2:
|
||||
oauth-sign@~0.8.1:
|
||||
version "0.8.2"
|
||||
resolved "https://registry.yarnpkg.com/oauth-sign/-/oauth-sign-0.8.2.tgz#46a6ab7f0aead8deae9ec0565780b7d4efeb9d43"
|
||||
|
||||
|
|
@ -4418,6 +4533,14 @@ output-file-sync@^1.1.2:
|
|||
mkdirp "^0.5.1"
|
||||
object-assign "^4.1.0"
|
||||
|
||||
"over@>= 0.0.5 < 1":
|
||||
version "0.0.5"
|
||||
resolved "https://registry.yarnpkg.com/over/-/over-0.0.5.tgz#f29852e70fd7e25f360e013a8ec44c82aedb5708"
|
||||
|
||||
p-cancelable@^0.3.0:
|
||||
version "0.3.0"
|
||||
resolved "https://registry.yarnpkg.com/p-cancelable/-/p-cancelable-0.3.0.tgz#b9e123800bcebb7ac13a479be195b507b98d30fa"
|
||||
|
||||
p-finally@^1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/p-finally/-/p-finally-1.0.0.tgz#3fbcfb15b899a44123b34b6dcc18b724336a2cae"
|
||||
|
|
@ -4436,6 +4559,12 @@ p-map@^1.1.1:
|
|||
version "1.2.0"
|
||||
resolved "https://registry.yarnpkg.com/p-map/-/p-map-1.2.0.tgz#e4e94f311eabbc8633a1e79908165fca26241b6b"
|
||||
|
||||
p-timeout@^1.1.1:
|
||||
version "1.2.1"
|
||||
resolved "https://registry.yarnpkg.com/p-timeout/-/p-timeout-1.2.1.tgz#5eb3b353b7fce99f101a1038880bb054ebbea386"
|
||||
dependencies:
|
||||
p-finally "^1.0.0"
|
||||
|
||||
pako@~0.2.0:
|
||||
version "0.2.9"
|
||||
resolved "https://registry.yarnpkg.com/pako/-/pako-0.2.9.tgz#f3f7522f4ef782348da8161bad9ecfd51bf83a75"
|
||||
|
|
@ -4543,10 +4672,6 @@ performance-now@^0.2.0:
|
|||
version "0.2.0"
|
||||
resolved "https://registry.yarnpkg.com/performance-now/-/performance-now-0.2.0.tgz#33ef30c5c77d4ea21c5a53869d91b56d8f2555e5"
|
||||
|
||||
performance-now@^2.1.0:
|
||||
version "2.1.0"
|
||||
resolved "https://registry.yarnpkg.com/performance-now/-/performance-now-2.1.0.tgz#6309f4e0e5fa913ec1c69307ae364b4b377c9e7b"
|
||||
|
||||
pify@^2.0.0:
|
||||
version "2.3.0"
|
||||
resolved "https://registry.yarnpkg.com/pify/-/pify-2.3.0.tgz#ed141a6ac043a849ea588498e7dca8b15330e90c"
|
||||
|
|
@ -4839,7 +4964,7 @@ prelude-ls@~1.1.2:
|
|||
version "1.1.2"
|
||||
resolved "https://registry.yarnpkg.com/prelude-ls/-/prelude-ls-1.1.2.tgz#21932a549f5e52ffd9a827f570e04be62a97da54"
|
||||
|
||||
prepend-http@^1.0.0:
|
||||
prepend-http@^1.0.0, prepend-http@^1.0.1:
|
||||
version "1.0.4"
|
||||
resolved "https://registry.yarnpkg.com/prepend-http/-/prepend-http-1.0.4.tgz#d4f4562b0ce3696e41ac52d0e002e57a635dc6dc"
|
||||
|
||||
|
|
@ -4906,6 +5031,15 @@ public-encrypt@^4.0.0:
|
|||
parse-asn1 "^5.0.0"
|
||||
randombytes "^2.0.1"
|
||||
|
||||
"pullstream@>= 0.4.1 < 1":
|
||||
version "0.4.1"
|
||||
resolved "https://registry.yarnpkg.com/pullstream/-/pullstream-0.4.1.tgz#d6fb3bf5aed697e831150eb1002c25a3f8ae1314"
|
||||
dependencies:
|
||||
over ">= 0.0.5 < 1"
|
||||
readable-stream "~1.0.31"
|
||||
setimmediate ">= 1.0.2 < 2"
|
||||
slice-stream ">= 1.0.0 < 2"
|
||||
|
||||
pump@^1.0.1:
|
||||
version "1.0.3"
|
||||
resolved "https://registry.yarnpkg.com/pump/-/pump-1.0.3.tgz#5dfe8311c33bbf6fc18261f9f34702c47c08a954"
|
||||
|
|
@ -4925,7 +5059,7 @@ q@^1.1.2:
|
|||
version "1.5.1"
|
||||
resolved "https://registry.yarnpkg.com/q/-/q-1.5.1.tgz#7e32f75b41381291d04611f1bf14109ac00651d7"
|
||||
|
||||
qs@6.5.1, qs@~6.5.1:
|
||||
qs@6.5.1:
|
||||
version "6.5.1"
|
||||
resolved "https://registry.yarnpkg.com/qs/-/qs-6.5.1.tgz#349cdf6eef89ec45c12d7d5eb3fc0c870343a6d8"
|
||||
|
||||
|
|
@ -5128,7 +5262,7 @@ read-pkg@^2.0.0:
|
|||
normalize-package-data "^2.3.2"
|
||||
path-type "^2.0.0"
|
||||
|
||||
"readable-stream@>=1.0.33-1 <1.1.0-0":
|
||||
"readable-stream@>=1.0.33-1 <1.1.0-0", readable-stream@~1.0.0, readable-stream@~1.0.31:
|
||||
version "1.0.34"
|
||||
resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-1.0.34.tgz#125820e34bc842d2f2aaafafe4c2916ee32c157c"
|
||||
dependencies:
|
||||
|
|
@ -5346,34 +5480,32 @@ repeating@^2.0.0:
|
|||
dependencies:
|
||||
is-finite "^1.0.0"
|
||||
|
||||
request@2:
|
||||
version "2.83.0"
|
||||
resolved "https://registry.yarnpkg.com/request/-/request-2.83.0.tgz#ca0b65da02ed62935887808e6f510381034e3356"
|
||||
request@2, request@~2.79.0:
|
||||
version "2.79.0"
|
||||
resolved "https://registry.yarnpkg.com/request/-/request-2.79.0.tgz#4dfe5bf6be8b8cdc37fcf93e04b65577722710de"
|
||||
dependencies:
|
||||
aws-sign2 "~0.7.0"
|
||||
aws4 "^1.6.0"
|
||||
caseless "~0.12.0"
|
||||
aws-sign2 "~0.6.0"
|
||||
aws4 "^1.2.1"
|
||||
caseless "~0.11.0"
|
||||
combined-stream "~1.0.5"
|
||||
extend "~3.0.1"
|
||||
extend "~3.0.0"
|
||||
forever-agent "~0.6.1"
|
||||
form-data "~2.3.1"
|
||||
har-validator "~5.0.3"
|
||||
hawk "~6.0.2"
|
||||
http-signature "~1.2.0"
|
||||
form-data "~2.1.1"
|
||||
har-validator "~2.0.6"
|
||||
hawk "~3.1.3"
|
||||
http-signature "~1.1.0"
|
||||
is-typedarray "~1.0.0"
|
||||
isstream "~0.1.2"
|
||||
json-stringify-safe "~5.0.1"
|
||||
mime-types "~2.1.17"
|
||||
oauth-sign "~0.8.2"
|
||||
performance-now "^2.1.0"
|
||||
qs "~6.5.1"
|
||||
safe-buffer "^5.1.1"
|
||||
stringstream "~0.0.5"
|
||||
tough-cookie "~2.3.3"
|
||||
tunnel-agent "^0.6.0"
|
||||
uuid "^3.1.0"
|
||||
mime-types "~2.1.7"
|
||||
oauth-sign "~0.8.1"
|
||||
qs "~6.3.0"
|
||||
stringstream "~0.0.4"
|
||||
tough-cookie "~2.3.0"
|
||||
tunnel-agent "~0.4.1"
|
||||
uuid "^3.0.0"
|
||||
|
||||
request@2.81.0:
|
||||
request@2.81.0, request@^2.81.0:
|
||||
version "2.81.0"
|
||||
resolved "https://registry.yarnpkg.com/request/-/request-2.81.0.tgz#c6928946a0e06c5f8d6f8a9333469ffda46298a0"
|
||||
dependencies:
|
||||
|
|
@ -5400,31 +5532,6 @@ request@2.81.0:
|
|||
tunnel-agent "^0.6.0"
|
||||
uuid "^3.0.0"
|
||||
|
||||
request@~2.79.0:
|
||||
version "2.79.0"
|
||||
resolved "https://registry.yarnpkg.com/request/-/request-2.79.0.tgz#4dfe5bf6be8b8cdc37fcf93e04b65577722710de"
|
||||
dependencies:
|
||||
aws-sign2 "~0.6.0"
|
||||
aws4 "^1.2.1"
|
||||
caseless "~0.11.0"
|
||||
combined-stream "~1.0.5"
|
||||
extend "~3.0.0"
|
||||
forever-agent "~0.6.1"
|
||||
form-data "~2.1.1"
|
||||
har-validator "~2.0.6"
|
||||
hawk "~3.1.3"
|
||||
http-signature "~1.1.0"
|
||||
is-typedarray "~1.0.0"
|
||||
isstream "~0.1.2"
|
||||
json-stringify-safe "~5.0.1"
|
||||
mime-types "~2.1.7"
|
||||
oauth-sign "~0.8.1"
|
||||
qs "~6.3.0"
|
||||
stringstream "~0.0.4"
|
||||
tough-cookie "~2.3.0"
|
||||
tunnel-agent "~0.4.1"
|
||||
uuid "^3.0.0"
|
||||
|
||||
require-directory@^2.1.1:
|
||||
version "2.1.1"
|
||||
resolved "https://registry.yarnpkg.com/require-directory/-/require-directory-2.1.1.tgz#8c64ad5fd30dab1c976e2344ffe7f792a6a6df42"
|
||||
|
|
@ -5620,7 +5727,7 @@ set-immediate-shim@^1.0.1:
|
|||
version "1.0.1"
|
||||
resolved "https://registry.yarnpkg.com/set-immediate-shim/-/set-immediate-shim-1.0.1.tgz#4b2b1b27eb808a9f8dcc481a58e5e56f599f3f61"
|
||||
|
||||
setimmediate@^1.0.4, setimmediate@^1.0.5:
|
||||
"setimmediate@>= 1.0.1 < 2", "setimmediate@>= 1.0.2 < 2", setimmediate@^1.0.4, setimmediate@^1.0.5:
|
||||
version "1.0.5"
|
||||
resolved "https://registry.yarnpkg.com/setimmediate/-/setimmediate-1.0.5.tgz#290cbb232e306942d7d7ea9b83732ab7856f8285"
|
||||
|
||||
|
|
@ -5685,18 +5792,24 @@ slice-ansi@0.0.4:
|
|||
version "0.0.4"
|
||||
resolved "https://registry.yarnpkg.com/slice-ansi/-/slice-ansi-0.0.4.tgz#edbf8903f66f7ce2f8eafd6ceed65e264c831b35"
|
||||
|
||||
slice-ansi@1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/slice-ansi/-/slice-ansi-1.0.0.tgz#044f1a49d8842ff307aad6b505ed178bd950134d"
|
||||
dependencies:
|
||||
is-fullwidth-code-point "^2.0.0"
|
||||
|
||||
"slice-stream@>= 1.0.0 < 2":
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/slice-stream/-/slice-stream-1.0.0.tgz#5b33bd66f013b1a7f86460b03d463dec39ad3ea0"
|
||||
dependencies:
|
||||
readable-stream "~1.0.31"
|
||||
|
||||
sntp@1.x.x:
|
||||
version "1.0.9"
|
||||
resolved "https://registry.yarnpkg.com/sntp/-/sntp-1.0.9.tgz#6541184cc90aeea6c6e7b35e2659082443c66198"
|
||||
dependencies:
|
||||
hoek "2.x.x"
|
||||
|
||||
sntp@2.x.x:
|
||||
version "2.1.0"
|
||||
resolved "https://registry.yarnpkg.com/sntp/-/sntp-2.1.0.tgz#2c6cec14fedc2222739caf9b5c3d85d1cc5a2cc8"
|
||||
dependencies:
|
||||
hoek "4.x.x"
|
||||
|
||||
sockjs-client@1.1.4:
|
||||
version "1.1.4"
|
||||
resolved "https://registry.yarnpkg.com/sockjs-client/-/sockjs-client-1.1.4.tgz#5babe386b775e4cf14e7520911452654016c8b12"
|
||||
|
|
@ -5822,11 +5935,7 @@ staged-git-files@0.0.4:
|
|||
version "0.0.4"
|
||||
resolved "https://registry.yarnpkg.com/staged-git-files/-/staged-git-files-0.0.4.tgz#d797e1b551ca7a639dec0237dc6eb4bb9be17d35"
|
||||
|
||||
"statuses@>= 1.3.1 < 2":
|
||||
version "1.4.0"
|
||||
resolved "https://registry.yarnpkg.com/statuses/-/statuses-1.4.0.tgz#bb73d446da2796106efcc1b601a253d6c46bd087"
|
||||
|
||||
statuses@~1.3.1:
|
||||
"statuses@>= 1.3.1 < 2", statuses@~1.3.1:
|
||||
version "1.3.1"
|
||||
resolved "https://registry.yarnpkg.com/statuses/-/statuses-1.3.1.tgz#faf51b9eb74aaef3b3acf4ad5f61abf24cb7b93e"
|
||||
|
||||
|
|
@ -5881,7 +5990,7 @@ string-width@^1.0.1, string-width@^1.0.2:
|
|||
is-fullwidth-code-point "^1.0.0"
|
||||
strip-ansi "^3.0.0"
|
||||
|
||||
string-width@^2.0.0:
|
||||
string-width@^2.0.0, string-width@^2.1.1:
|
||||
version "2.1.1"
|
||||
resolved "https://registry.yarnpkg.com/string-width/-/string-width-2.1.1.tgz#ab93f27a8dc13d28cac815c462143a6d9012ae9e"
|
||||
dependencies:
|
||||
|
|
@ -5902,7 +6011,7 @@ string_decoder@^1.0.0, string_decoder@~1.0.3:
|
|||
dependencies:
|
||||
safe-buffer "~5.1.0"
|
||||
|
||||
stringstream@~0.0.4, stringstream@~0.0.5:
|
||||
stringstream@~0.0.4:
|
||||
version "0.0.5"
|
||||
resolved "https://registry.yarnpkg.com/stringstream/-/stringstream-0.0.5.tgz#4e484cd4de5a0bbbee18e46307710a8a81621878"
|
||||
|
||||
|
|
@ -5992,6 +6101,17 @@ table@^3.7.8:
|
|||
slice-ansi "0.0.4"
|
||||
string-width "^2.0.0"
|
||||
|
||||
table@^4.0.1:
|
||||
version "4.0.2"
|
||||
resolved "https://registry.yarnpkg.com/table/-/table-4.0.2.tgz#a33447375391e766ad34d3486e6e2aedc84d2e36"
|
||||
dependencies:
|
||||
ajv "^5.2.3"
|
||||
ajv-keywords "^2.1.0"
|
||||
chalk "^2.1.0"
|
||||
lodash "^4.17.4"
|
||||
slice-ansi "1.0.0"
|
||||
string-width "^2.1.1"
|
||||
|
||||
tapable@^0.1.8, tapable@~0.1.8:
|
||||
version "0.1.10"
|
||||
resolved "https://registry.yarnpkg.com/tapable/-/tapable-0.1.10.tgz#29c35707c2b70e50d07482b5d202e8ed446dafd4"
|
||||
|
|
@ -6032,7 +6152,7 @@ through2@^0.6.2, through2@^0.6.5:
|
|||
readable-stream ">=1.0.33-1 <1.1.0-0"
|
||||
xtend ">=4.0.0 <4.1.0-0"
|
||||
|
||||
through@^2.3.6, through@~2.3.4:
|
||||
through@^2.3.6, through@^2.3.8, through@~2.3.4:
|
||||
version "2.3.8"
|
||||
resolved "https://registry.yarnpkg.com/through/-/through-2.3.8.tgz#0dd4c9ffaabc357960b1b724115d7e0e86a2e1f5"
|
||||
|
||||
|
|
@ -6044,6 +6164,10 @@ time-stamp@^2.0.0:
|
|||
version "2.0.0"
|
||||
resolved "https://registry.yarnpkg.com/time-stamp/-/time-stamp-2.0.0.tgz#95c6a44530e15ba8d6f4a3ecb8c3a3fac46da357"
|
||||
|
||||
timed-out@^4.0.0:
|
||||
version "4.0.1"
|
||||
resolved "https://registry.yarnpkg.com/timed-out/-/timed-out-4.0.1.tgz#f32eacac5a175bea25d7fab565ab3ed8741ef56f"
|
||||
|
||||
timers-browserify@^2.0.2, timers-browserify@^2.0.4:
|
||||
version "2.0.4"
|
||||
resolved "https://registry.yarnpkg.com/timers-browserify/-/timers-browserify-2.0.4.tgz#96ca53f4b794a5e7c0e1bd7cc88a372298fa01e6"
|
||||
|
|
@ -6058,12 +6182,16 @@ to-fast-properties@^1.0.3:
|
|||
version "1.0.3"
|
||||
resolved "https://registry.yarnpkg.com/to-fast-properties/-/to-fast-properties-1.0.3.tgz#b83571fa4d8c25b82e231b06e3a3055de4ca1a47"
|
||||
|
||||
tough-cookie@~2.3.0, tough-cookie@~2.3.3:
|
||||
tough-cookie@~2.3.0:
|
||||
version "2.3.3"
|
||||
resolved "https://registry.yarnpkg.com/tough-cookie/-/tough-cookie-2.3.3.tgz#0b618a5565b6dea90bf3425d04d55edc475a7561"
|
||||
dependencies:
|
||||
punycode "^1.4.1"
|
||||
|
||||
"traverse@>=0.3.0 <0.4":
|
||||
version "0.3.9"
|
||||
resolved "https://registry.yarnpkg.com/traverse/-/traverse-0.3.9.tgz#717b8f220cc0bb7b44e40514c22b2e8bbc70d8b9"
|
||||
|
||||
trim-newlines@^1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/trim-newlines/-/trim-newlines-1.0.0.tgz#5887966bb582a4503a41eb524f7d35011815a613"
|
||||
|
|
@ -6193,6 +6321,23 @@ unreachable-branch-transform@^0.3.0:
|
|||
recast "^0.10.1"
|
||||
through2 "^0.6.2"
|
||||
|
||||
unzip@^0.1.11:
|
||||
version "0.1.11"
|
||||
resolved "https://registry.yarnpkg.com/unzip/-/unzip-0.1.11.tgz#89749c63b058d7d90d619f86b98aa1535d3b97f0"
|
||||
dependencies:
|
||||
binary ">= 0.3.0 < 1"
|
||||
fstream ">= 0.1.30 < 1"
|
||||
match-stream ">= 0.0.2 < 1"
|
||||
pullstream ">= 0.4.1 < 1"
|
||||
readable-stream "~1.0.31"
|
||||
setimmediate ">= 1.0.1 < 2"
|
||||
|
||||
url-parse-lax@^1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/url-parse-lax/-/url-parse-lax-1.0.0.tgz#7af8f303645e9bd79a272e7a14ac68bc0609da73"
|
||||
dependencies:
|
||||
prepend-http "^1.0.1"
|
||||
|
||||
url-parse@1.0.x:
|
||||
version "1.0.5"
|
||||
resolved "https://registry.yarnpkg.com/url-parse/-/url-parse-1.0.5.tgz#0854860422afdcfefeb6c965c662d4800169927b"
|
||||
|
|
@ -6207,6 +6352,10 @@ url-parse@^1.1.8:
|
|||
querystringify "~1.0.0"
|
||||
requires-port "~1.0.0"
|
||||
|
||||
url-to-options@^1.0.1:
|
||||
version "1.0.1"
|
||||
resolved "https://registry.yarnpkg.com/url-to-options/-/url-to-options-1.0.1.tgz#1505a03a289a48cbd7a434efbaeec5055f5633a9"
|
||||
|
||||
url@^0.11.0:
|
||||
version "0.11.0"
|
||||
resolved "https://registry.yarnpkg.com/url/-/url-0.11.0.tgz#3838e97cfc60521eb73c525a8e55bfdd9e2e28f1"
|
||||
|
|
@ -6242,7 +6391,7 @@ uuid@^2.0.2:
|
|||
version "2.0.3"
|
||||
resolved "https://registry.yarnpkg.com/uuid/-/uuid-2.0.3.tgz#67e2e863797215530dff318e5bf9dcebfd47b21a"
|
||||
|
||||
uuid@^3.0.0, uuid@^3.1.0:
|
||||
uuid@^3.0.0:
|
||||
version "3.1.0"
|
||||
resolved "https://registry.yarnpkg.com/uuid/-/uuid-3.1.0.tgz#3dd3d3e790abc24d7b0d3a034ffababe28ebbc04"
|
||||
|
||||
|
|
@ -6470,7 +6619,7 @@ which-module@^2.0.0:
|
|||
version "2.0.0"
|
||||
resolved "https://registry.yarnpkg.com/which-module/-/which-module-2.0.0.tgz#d9ef07dce77b9902b8a3a8fa4b31c3e3f7e6e87a"
|
||||
|
||||
which@1, which@^1.0.5, which@^1.2.10, which@^1.2.9:
|
||||
which@1, which@^1.0.5, which@^1.2.10, which@^1.2.14, which@^1.2.9:
|
||||
version "1.3.0"
|
||||
resolved "https://registry.yarnpkg.com/which/-/which-1.3.0.tgz#ff04bdfc010ee547d780bec38e1ac1c2777d253a"
|
||||
dependencies:
|
||||
|
|
@ -6486,6 +6635,10 @@ window-size@0.1.0:
|
|||
version "0.1.0"
|
||||
resolved "https://registry.yarnpkg.com/window-size/-/window-size-0.1.0.tgz#5438cd2ea93b202efa3a19fe8887aee7c94f9c9d"
|
||||
|
||||
window-size@^0.2.0:
|
||||
version "0.2.0"
|
||||
resolved "https://registry.yarnpkg.com/window-size/-/window-size-0.2.0.tgz#b4315bb4214a3d7058ebeee892e13fa24d98b075"
|
||||
|
||||
wordwrap@0.0.2:
|
||||
version "0.0.2"
|
||||
resolved "https://registry.yarnpkg.com/wordwrap/-/wordwrap-0.0.2.tgz#b79669bb42ecb409f83d583cad52ca17eaa1643f"
|
||||
|
|
@ -6531,6 +6684,13 @@ yallist@^2.1.2:
|
|||
version "2.1.2"
|
||||
resolved "https://registry.yarnpkg.com/yallist/-/yallist-2.1.2.tgz#1c11f9218f076089a47dd512f93c6699a6a81d52"
|
||||
|
||||
yargs-parser@^2.4.1:
|
||||
version "2.4.1"
|
||||
resolved "https://registry.yarnpkg.com/yargs-parser/-/yargs-parser-2.4.1.tgz#85568de3cf150ff49fa51825f03a8c880ddcc5c4"
|
||||
dependencies:
|
||||
camelcase "^3.0.0"
|
||||
lodash.assign "^4.0.6"
|
||||
|
||||
yargs-parser@^4.2.0:
|
||||
version "4.2.1"
|
||||
resolved "https://registry.yarnpkg.com/yargs-parser/-/yargs-parser-4.2.1.tgz#29cceac0dc4f03c6c87b4a9f217dd18c9f74871c"
|
||||
|
|
@ -6549,6 +6709,25 @@ yargs-parser@^7.0.0:
|
|||
dependencies:
|
||||
camelcase "^4.1.0"
|
||||
|
||||
yargs@^4.2.0:
|
||||
version "4.8.1"
|
||||
resolved "https://registry.yarnpkg.com/yargs/-/yargs-4.8.1.tgz#c0c42924ca4aaa6b0e6da1739dfb216439f9ddc0"
|
||||
dependencies:
|
||||
cliui "^3.2.0"
|
||||
decamelize "^1.1.1"
|
||||
get-caller-file "^1.0.1"
|
||||
lodash.assign "^4.0.3"
|
||||
os-locale "^1.4.0"
|
||||
read-pkg-up "^1.0.1"
|
||||
require-directory "^2.1.1"
|
||||
require-main-filename "^1.0.1"
|
||||
set-blocking "^2.0.0"
|
||||
string-width "^1.0.1"
|
||||
which-module "^1.0.0"
|
||||
window-size "^0.2.0"
|
||||
y18n "^3.2.1"
|
||||
yargs-parser "^2.4.1"
|
||||
|
||||
yargs@^6.6.0:
|
||||
version "6.6.0"
|
||||
resolved "https://registry.yarnpkg.com/yargs/-/yargs-6.6.0.tgz#782ec21ef403345f830a808ca3d513af56065208"
|
||||
|
|
|
|||
Maybe add a link to flow docs for each of these cases?