ShapeShift integration #652

Merged
neb-b merged 7 commits from shapeshift into master 2017-12-06 01:33:41 +01:00
43 changed files with 1477 additions and 179 deletions

View file

@ -12,6 +12,9 @@ flow-typed
suppress_comment=\\(.\\|\n\\)*\\$FlowFixMe suppress_comment=\\(.\\|\n\\)*\\$FlowFixMe
suppress_comment=\\(.\\|\n\\)*\\$FlowIssue suppress_comment=\\(.\\|\n\\)*\\$FlowIssue
module.name_mapper='^constants\(.*\)$' -> '<PROJECT_ROOT>/js/constants\1' module.name_mapper='^constants\(.*\)$' -> '<PROJECT_ROOT>/js/constants\1'
module.name_mapper='^util\(.*\)$' -> '<PROJECT_ROOT>/js/util\1'
module.name_mapper='^redux\(.*\)$' -> '<PROJECT_ROOT>/js/redux\1' module.name_mapper='^redux\(.*\)$' -> '<PROJECT_ROOT>/js/redux\1'
module.name_mapper='^types\(.*\)$' -> '<PROJECT_ROOT>/js/types\1'
module.name_mapper='^component\(.*\)$' -> '<PROJECT_ROOT>/js/component\1'
[strict] [strict]

3
src/renderer/flow-typed/bluebird.js vendored Normal file
View file

@ -0,0 +1,3 @@
declare module 'bluebird' {
neb-b commented 2017-12-04 04:36:24 +01:00 (Migrated from github.com)
Review

There's got to be a better way to do this. Can these be added to the .flowconfig?

There's got to be a better way to do this. Can these be added to the `.flowconfig`?
liamcardenas commented 2017-12-04 21:05:37 +01:00 (Migrated from github.com)
Review

Have you checked if flow-typed has any of the type definitions?

https://github.com/flowtype/flow-typed

yarn run flow-typed install bluebird

Have you checked if flow-typed has any of the type definitions? https://github.com/flowtype/flow-typed `yarn run flow-typed install bluebird`
declare module.exports: any;
}

3
src/renderer/flow-typed/classnames.js vendored Normal file
View file

@ -0,0 +1,3 @@
declare module 'classnames' {
declare module.exports: any;
}

3
src/renderer/flow-typed/formik.js vendored Normal file
View file

@ -0,0 +1,3 @@
declare module 'formik' {
declare module.exports: any;
}

1
src/renderer/flow-typed/i18n.js vendored Normal file
View file

@ -0,0 +1 @@
declare function __(a: string): string;

View file

@ -0,0 +1,3 @@
declare module 'qrcode.react' {
declare module.exports: any;
}

View file

@ -0,0 +1,3 @@
declare module 'shapeshift.io' {
declare module.exports: any;
}

View file

@ -0,0 +1,7 @@
import { connect } from "react-redux";
import { doShowSnackBar } from "redux/actions/app";
import Address from "./view";
export default connect(null, {
doShowSnackBar,
})(Address);

View file

@ -0,0 +1,52 @@
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
import React from "react";
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
import PropTypes from "prop-types";
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
import { clipboard } from "electron";
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
import Link from "component/link";
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
import classnames from "classnames";
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
export default class Address extends React.PureComponent {
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
static propTypes = {
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
address: PropTypes.string,
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
};
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
constructor(props) {
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
super(props);
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
this._inputElem = null;
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
}
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
render() {
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
const { address, showCopyButton, doShowSnackBar } = this.props;
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
return (
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
<div className="form-field form-field--address">
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
<input
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
className={classnames("input-copyable", {
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
"input-copyable--with-copy-btn": showCopyButton,
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
})}
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
type="text"
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
ref={input => {
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
this._inputElem = input;
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
}}
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
onFocus={() => {
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
this._inputElem.select();
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
}}
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
readOnly="readonly"
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
value={address || ""}
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
/>
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
{showCopyButton && (
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
<span className="header__item">
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
<Link
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
button="alt button--flat"
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
icon="clipboard"
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
onClick={() => {
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
clipboard.writeText(address);
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
doShowSnackBar({ message: __("Address copied") });
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
}}
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
/>
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
</span>
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
)}
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
</div>
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
);
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
}
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍
}
neb-b commented 2017-11-29 18:08:39 +01:00 (Migrated from github.com)
Review

Whoops. You're right. I'll update

Whoops. You're right. I'll update
neb-b commented 2017-11-29 18:17:40 +01:00 (Migrated from github.com)
Review

all good now 👍

all good now 👍

View file

@ -137,42 +137,6 @@ export class CreditAmount extends React.PureComponent {
} }
} }
let addressStyle = {
fontFamily:
'"Consolas", "Lucida Console", "Adobe Source Code Pro", monospace',
};
export class Address extends React.PureComponent {
static propTypes = {
address: PropTypes.string,
};
constructor(props) {
super(props);
this._inputElem = null;
}
render() {
return (
<div className="form-field form-field--address">
<input
className="input-copyable"
type="text"
ref={input => {
this._inputElem = input;
}}
onFocus={() => {
this._inputElem.select();
}}
style={addressStyle}
readOnly="readonly"
value={this.props.address || ""}
/>
</div>
);
}
}
export class Thumbnail extends React.PureComponent { export class Thumbnail extends React.PureComponent {
static propTypes = { static propTypes = {
src: PropTypes.string, src: PropTypes.string,

View file

@ -0,0 +1,16 @@
import React from "react";
import classnames from "classnames";
export default ({ dark, className }) => {
return (
<div
className={classnames(
"spinner",
{
"spinner--dark": dark,
},
className
)}
/>
);
};

View file

@ -14,11 +14,12 @@ const Link = props => {
navigate, navigate,
navigateParams, navigateParams,
doNavigate, doNavigate,
className,
} = props; } = props;
const className = const combinedClassName =
(props.className || "") + (className || "") +
(!props.className && !button ? "button-text" : "") + // Non-button links get the same look as text buttons (!className && !button ? "button-text" : "") + // Non-button links get the same look as text buttons
(button ? " button-block button-" + button + " button-set-item" : "") + (button ? " button-block button-" + button + " button-set-item" : "") +
(disabled ? " disabled" : ""); (disabled ? " disabled" : "");
@ -43,7 +44,7 @@ const Link = props => {
return ( return (
<a <a
className={className} className={combinedClassName}
href={href || "javascript:;"} href={href || "javascript:;"}
title={title} title={title}
onClick={onClick} onClick={onClick}

View file

@ -0,0 +1,26 @@
import { connect } from "react-redux";
import {
createShapeShift,
shapeShiftInit,
getCoinStats,
clearShapeShift,
getActiveShift,
} from "redux/actions/shape_shift";
import { doShowSnackBar } from "redux/actions/app";
import { selectReceiveAddress } from "redux/selectors/wallet";
import { selectShapeShift } from "redux/selectors/shape_shift";
import ShapeShift from "./view";
const select = state => ({
receiveAddress: selectReceiveAddress(state),
shapeShift: selectShapeShift(state),
});
export default connect(select, {
shapeShiftInit,
getCoinStats,
createShapeShift,
clearShapeShift,
getActiveShift,
doShowSnackBar,
})(ShapeShift);

View file

@ -0,0 +1,161 @@
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
// @flow
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
import * as React from "react";
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
import QRCode from "qrcode.react";
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
import * as statuses from "constants/shape_shift";
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
import Address from "component/address";
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
import Link from "component/link";
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
import type { Dispatch } from "redux/actions/shape_shift";
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
import ShiftMarketInfo from "./market_info";
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
type Props = {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftState: ?string,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftCoinType: ?string,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftDepositAddress: ?string,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftReturnAddress: ?string,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftOrderId: ?string,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositMax: ?number,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
clearShapeShift: Dispatch,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
doShowSnackBar: Dispatch,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
getActiveShift: Dispatch,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shapeShiftRate: ?number,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositMax: ?number,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositFee: ?number,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositMin: ?string,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
};
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
class ActiveShapeShift extends React.PureComponent<Props> {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
continousFetch: ?number;
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
constructor() {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
super();
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
this.continousFetch = undefined;
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
componentDidMount() {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
const { getActiveShift, shiftDepositAddress } = this.props;
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
getActiveShift(shiftDepositAddress);
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
this.continousFetch = setInterval(() => {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
getActiveShift(shiftDepositAddress);
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}, 10000);
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
componentWillUpdate(nextProps: Props) {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
const { shiftState } = nextProps;
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
if (shiftState === statuses.COMPLETE) {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
this.clearContinuousFetch();
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
componentWillUnmount() {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
this.clearContinuousFetch();
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
clearContinuousFetch() {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
if (this.continousFetch) {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
clearInterval(this.continousFetch);
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
this.continousFetch = null;
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
render() {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
const {
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftCoinType,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftDepositAddress,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftReturnAddress,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftOrderId,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftState,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositMax,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
clearShapeShift,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
doShowSnackBar,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shapeShiftRate,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositFee,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositMin,
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
} = this.props;
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
return (
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
{shiftState === statuses.NO_DEPOSITS && (
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<p>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
Send up to{" "}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<span className="credit-amount--bold">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
{originCoinDepositMax} {shiftCoinType}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</span>{" "}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
to the address below.
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</p>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<ShiftMarketInfo
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoin={shiftCoinType}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shapeShiftRate={shapeShiftRate}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositFee={originCoinDepositFee}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositMin={originCoinDepositMin}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
originCoinDepositMax={originCoinDepositMax}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
/>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<div className="shapeshift__deposit-address-wrapper">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<Address address={shiftDepositAddress} showCopyButton />
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<div className="shapeshift__qrcode">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<QRCode value={shiftDepositAddress} />
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
)}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
{shiftState === statuses.RECEIVED && (
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<div className="card__content--extra-vertical-space">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<p>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
{__(
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
"ShapeShift has received your payment! Sending the funds to your LBRY wallet."
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
)}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</p>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<span className="help">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
{__("This can take a while, especially with BTC.")}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</span>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
)}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
{shiftState === statuses.COMPLETE && (
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<div className="card__content--extra-vertical-space">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<p>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
{__(
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
"Transaction complete! You should see the new LBC in your wallet."
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
)}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</p>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
)}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<div className="card__actions card__actions--only-vertical">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<Link
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
button={shiftState === statuses.COMPLETE ? "primary" : "alt"}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
onClick={clearShapeShift}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
label={
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftState === statuses.COMPLETE ||
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftState === statuses.RECEIVED
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
? __("Done")
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
: __("Cancel")
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
/>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
{shiftOrderId && (
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<span className="shapeshift__link">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<Link
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
button="text"
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
label={__("View the status on Shapeshift.io")}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
href={`https://shapeshift.io/#/status/${shiftOrderId}`}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
/>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</span>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
)}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
{shiftState === statuses.NO_DEPOSITS &&
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
shiftReturnAddress && (
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<div className="shapeshift__actions-help">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
<span className="help">
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
If the transaction doesn't go through, ShapeShift will return
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
your {shiftCoinType} back to {shiftReturnAddress}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</span>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
)}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
</div>
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
);
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
}
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes
export default ActiveShapeShift;
neb-b commented 2017-11-28 23:38:32 +01:00 (Migrated from github.com)
Review

Good idea

Good idea
kauffj commented 2017-11-30 02:42:13 +01:00 (Migrated from github.com)
Review

Try button="text" here.

Try `button="text"` here.
kauffj commented 2017-11-30 02:42:49 +01:00 (Migrated from github.com)
Review

Add "."

Add "."
kauffj commented 2017-11-30 02:46:52 +01:00 (Migrated from github.com)
Review

Add ".". Also, let's link to FAQ here again.

Add ".". Also, let's link to FAQ here again.
kauffj commented 2017-11-30 02:49:16 +01:00 (Migrated from github.com)
Review

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.

I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don't necessary want to do a new one. I just want it back to where it was. Not sure on best name for this.
kauffj commented 2017-11-30 02:49:26 +01:00 (Migrated from github.com)
Review

Also this should probably be primary, whatever the label is.

Also this should probably be primary, whatever the label is.
neb-b commented 2017-12-04 18:24:37 +01:00 (Migrated from github.com)
Review

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better).

We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"

I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift status page, I don't see any reason to create another shift status "user says they sent it but shapeshift hasn't received it"
liamcardenas commented 2017-12-04 21:14:00 +01:00 (Migrated from github.com)
Review

outside of the constructor, I think you need to add

continuousFetch: ?number;

as per https://flow.org/en/docs/types/classes/

outside of the constructor, I think you need to add `continuousFetch: ?number;` as per https://flow.org/en/docs/types/classes/
liamcardenas commented 2017-12-04 21:14:19 +01:00 (Migrated from github.com)
Review

this should get rid of all the flow fix mes

this should get rid of all the flow fix mes

View file

@ -0,0 +1,109 @@
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
import React from "react";
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
import Link from "component/link";
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
import { getExampleAddress } from "util/shape_shift";
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
import { Submit, FormRow } from "component/form";
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
import type { ShapeShiftFormValues, Dispatch } from "redux/actions/shape_shift";
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
import ShiftMarketInfo from "./market_info";
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
type ShapeShiftFormErrors = {
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
returnAddress?: string,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
};
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
type Props = {
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
values: ShapeShiftFormValues,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
errors: ShapeShiftFormErrors,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
touched: boolean,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
handleChange: Event => any,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
handleBlur: Event => any,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
handleSubmit: Event => any,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
isSubmitting: boolean,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
shiftSupportedCoins: Array<string>,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoin: string,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
updating: boolean,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
getCoinStats: Dispatch,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
receiveAddress: string,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositFee: number,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositMin: string,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositMax: number,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
shapeShiftRate: number,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
};
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
export default (props: Props) => {
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
const {
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
values,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
errors,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
touched,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
handleChange,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
handleBlur,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
handleSubmit,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
isSubmitting,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
shiftSupportedCoins,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoin,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
updating,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
getCoinStats,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
receiveAddress,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositMax,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositMin,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositFee,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
shapeShiftRate,
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
} = props;
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
return (
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<form onSubmit={handleSubmit}>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<div className="form-field">
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<span>{__("Exchange")} </span>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<select
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
className="form-field__input form-field__input-select"
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
name="originCoin"
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
onChange={e => {
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
getCoinStats(e.target.value);
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
handleChange(e);
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
}}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
{shiftSupportedCoins.map(coin => (
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<option key={coin} value={coin}>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
{coin}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
</option>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
))}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
</select>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<span> {__("for LBC")}</span>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<div className="shapeshift__tx-info">
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
{!updating &&
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositMax && (
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<ShiftMarketInfo
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoin={originCoin}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
shapeShiftRate={shapeShiftRate}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositFee={originCoinDepositFee}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositMin={originCoinDepositMin}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
originCoinDepositMax={originCoinDepositMax}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
/>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
)}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
</div>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
</div>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<FormRow
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
type="text"
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
name="returnAddress"
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
placeholder={getExampleAddress(originCoin)}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
label={__("Return address")}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
onChange={handleChange}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
onBlur={handleBlur}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
value={values.returnAddress}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
errorMessage={errors.returnAddress}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
hasError={touched.returnAddress && !!errors.returnAddress}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
/>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<span className="help">
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<span>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
({__("optional but recommended")}) {__("We will return your")}{" "}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
{originCoin}{" "}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
{__("to this address if the transaction doesn't go through.")}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
</span>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
</span>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<div className="card__actions card__actions--only-vertical">
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
<Submit
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
label={__("Begin Conversion")}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
disabled={isSubmitting || !!Object.keys(errors).length}
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
/>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
</div>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
</form>
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
);
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that
};
neb-b commented 2017-11-30 02:54:09 +01:00 (Migrated from github.com)
Review

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic input style to be more inline with the wunderbar

Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
neb-b commented 2017-11-30 06:18:07 +01:00 (Migrated from github.com)
Review

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this:

Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle.

For this element (select), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this select element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the FormRow component uses).

If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change.

Would love to hear everyone else's thoughts. @liamcardenas @IGassmann

I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element (`select`), there can be many different ways to present it. I think it definitely makes sense to use a shared components if there might be inline errors or something we want to keep the same across the app, but there won't be any errors on this `select` element. I just want the styling with text on the left and right, which is very easy just by using regular html elements (and the same classes that the `FormRow` component uses). If we start building out the shared components so much that they meet every possible use case, they can quickly become huge, un-maintainable files that can be terrible pain to update/change. Would love to hear everyone else's thoughts. @liamcardenas @IGassmann
neb-b commented 2017-12-04 17:38:54 +01:00 (Migrated from github.com)
Review

Yes we can display the actual rate. I'll add that

Yes we can display the actual rate. I'll add that

View file

@ -0,0 +1,34 @@
// @flow
import React from "react";
type Props = {
shapeShiftRate: ?number,
originCoin: ?string,
originCoinDepositFee: ?number,
originCoinDepositMax: ?number,
originCoinDepositMin: ?string,
};
export default (props: Props) => {
const {
shapeShiftRate,
originCoin,
originCoinDepositFee,
originCoinDepositMax,
originCoinDepositMin,
} = props;
return (
<div>
<span className="help">
{__("Receive")} {shapeShiftRate} LBC
{" / "}
{"1"} {originCoin} {__("less")} {originCoinDepositFee} LBC {__("fee")}.
<br />
{__("Exchange max")}: {originCoinDepositMax} {originCoin}
<br />
{__("Exchange min")}: {originCoinDepositMin} {originCoin}
</span>
</div>
);
};

View file

@ -0,0 +1,150 @@
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
// @flow
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import * as React from "react";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import { shell } from "electron";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import { Formik } from "formik";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import classnames from "classnames";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import * as statuses from "constants/shape_shift";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import { validateShapeShiftForm } from "util/shape_shift";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import Link from "component/link";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import Spinner from "component/common/spinner";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import { BusyMessage } from "component/common";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import ShapeShiftForm from "./internal/form";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import ActiveShapeShift from "./internal/active-shift";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import type { ShapeShiftState } from "redux/reducers/shape_shift";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
import type { Dispatch, ShapeShiftFormValues } from "redux/actions/shape_shift";
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
type Props = {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shapeShift: ShapeShiftState,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
getCoinStats: Dispatch,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
createShapeShift: Dispatch,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
clearShapeShift: Dispatch,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
getActiveShift: Dispatch,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
doShowSnackBar: Dispatch,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shapeShiftInit: Dispatch,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
receiveAddress: string,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
};
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
class ShapeShift extends React.PureComponent<Props> {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
componentDidMount() {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
const {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shapeShiftInit,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shapeShift: { hasActiveShift, shiftSupportedCoins },
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
} = this.props;
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
if (!hasActiveShift && !shiftSupportedCoins.length) {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
// calls shapeshift to see list of supported coins for shifting
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shapeShiftInit();
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
render() {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
const {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
getCoinStats,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
receiveAddress,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
createShapeShift,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shapeShift,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
clearShapeShift,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
getActiveShift,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
doShowSnackBar,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
} = this.props;
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
const {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
loading,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
updating,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
error,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftSupportedCoins,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
hasActiveShift,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoin,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
// ShapeShift response values
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositMax,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositMin,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositFee,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftDepositAddress,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftReturnAddress,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftCoinType,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftOrderId,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftState,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shapeShiftRate,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
} = shapeShift;
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
const initialFormValues: ShapeShiftFormValues = {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
receiveAddress,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoin: "BTC",
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
returnAddress: "",
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
};
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
return (
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
// add the "shapeshift__intital-wrapper class so we can avoid content jumping once everything loads"
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
// it just gives the section a min-height equal to the height of the content when the form is rendered
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
// if the markup below changes for the initial render (form.jsx) there will be content jumping
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
// the styling in shapeshift.scss will need to be updated to the correct min-height
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<section
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
className={classnames("card shapeshift__wrapper", {
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
"shapeshift__initial-wrapper": loading,
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
})}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<div className="card__title-primary">
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<h3>{__("Convert Crypto to LBC")}</h3>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<p className="help">
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
{__("Powered by ShapeShift. Read our FAQ")}{" "}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<Link href="https://lbry.io/faq/shapeshift">{__("here")}</Link>.
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
{hasActiveShift &&
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftState !== "complete" && (
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<span>{__("This will update automatically.")}</span>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
)}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
</p>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
</div>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<div className="card__content shapeshift__content">
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
{error && <div className="form-field__error">{error}</div>}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
{loading && <Spinner dark />}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
{!loading &&
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
!hasActiveShift &&
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
!!shiftSupportedCoins.length && (
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<Formik
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
onSubmit={createShapeShift}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
validate={validateShapeShiftForm}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
initialValues={initialFormValues}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
render={formProps => (
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<ShapeShiftForm
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
{...formProps}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
updating={updating}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoin={originCoin}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftSupportedCoins={shiftSupportedCoins}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
getCoinStats={getCoinStats}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
receiveAddress={receiveAddress}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositMax={originCoinDepositMax}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositMin={originCoinDepositMin}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositFee={originCoinDepositFee}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shapeShiftRate={shapeShiftRate}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
updating={updating}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
/>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
)}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
/>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
)}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
{hasActiveShift && (
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
<ActiveShapeShift
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
getActiveShift={getActiveShift}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftCoinType={shiftCoinType}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftReturnAddress={shiftReturnAddress}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftDepositAddress={shiftDepositAddress}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositMax={originCoinDepositMax}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftOrderId={shiftOrderId}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shiftState={shiftState}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
clearShapeShift={clearShapeShift}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
doShowSnackBar={doShowSnackBar}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositMax={originCoinDepositMax}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositMin={originCoinDepositMin}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
originCoinDepositFee={originCoinDepositFee}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
shapeShiftRate={shapeShiftRate}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
updating={updating}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
/>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
)}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
</div>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
</section>
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
);
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
}
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up
export default ShapeShift;
neb-b commented 2017-11-30 02:46:51 +01:00 (Migrated from github.com)
Review

I was thinking this would be a link to the FAQ Tom writes up

I was thinking this would be a link to the FAQ Tom writes up

View file

@ -1,9 +1,10 @@
import React from "react"; import React from "react";
import Spinner from "component/common/spinner";
const LoadingScreen = ({ status, spinner = true }) => ( const LoadingScreen = ({ status, spinner = true }) => (
<div className="video__loading-screen"> <div className="video__loading-screen">
<div> <div>
{spinner && <div className="video__loading-spinner" />} {spinner && <Spinner />}
<div className="video__loading-status">{status}</div> <div className="video__loading-status">{status}</div>
</div> </div>

View file

@ -1,6 +1,6 @@
import React from "react"; import React from "react";
import Link from "component/link"; import Link from "component/link";
import { Address } from "component/common"; import Address from "component/address";
class WalletAddress extends React.PureComponent { class WalletAddress extends React.PureComponent {
componentWillMount() { componentWillMount() {

View file

@ -144,3 +144,18 @@ export const FETCH_REWARD_CONTENT_COMPLETED = "FETCH_REWARD_CONTENT_COMPLETED";
//Language //Language
export const DOWNLOAD_LANGUAGE_SUCCEEDED = "DOWNLOAD_LANGUAGE_SUCCEEDED"; export const DOWNLOAD_LANGUAGE_SUCCEEDED = "DOWNLOAD_LANGUAGE_SUCCEEDED";
export const DOWNLOAD_LANGUAGE_FAILED = "DOWNLOAD_LANGUAGE_FAILED"; export const DOWNLOAD_LANGUAGE_FAILED = "DOWNLOAD_LANGUAGE_FAILED";
// ShapeShift
export const GET_SUPPORTED_COINS_START = "GET_SUPPORTED_COINS_START";
export const GET_SUPPORTED_COINS_SUCCESS = "GET_SUPPORTED_COINS_SUCCESS";
export const GET_SUPPORTED_COINS_FAIL = "GET_SUPPORTED_COINS_FAIL";
export const GET_COIN_STATS_START = "GET_COIN_STATS_START";
export const GET_COIN_STATS_SUCCESS = "GET_COIN_STATS_SUCCESS";
export const GET_COIN_STATS_FAIL = "GET_COIN_STATS_FAIL";
export const PREPARE_SHAPE_SHIFT_START = "PREPARE_SHAPE_SHIFT_START";
export const PREPARE_SHAPE_SHIFT_SUCCESS = "PREPARE_SHAPE_SHIFT_SUCCESS";
export const PREPARE_SHAPE_SHIFT_FAIL = "PREPARE_SHAPE_SHIFT_FAIL";
export const GET_ACTIVE_SHIFT_START = "GET_ACTIVE_SHIFT_START";
export const GET_ACTIVE_SHIFT_SUCCESS = "GET_ACTIVE_SHIFT_SUCCESS";
export const GET_ACTIVE_SHIFT_FAIL = "GET_ACTIVE_SHIFT_FAIL";
export const CLEAR_SHAPE_SHIFT = "CLEAR_SHAPE_SHIFT";

View file

@ -0,0 +1,3 @@
export const NO_DEPOSITS = "no_deposits";
export const RECEIVED = "received";
export const COMPLETE = "complete";

View file

@ -2,15 +2,17 @@ import React from "react";
import SubHeader from "component/subHeader"; import SubHeader from "component/subHeader";
import Link from "component/link"; import Link from "component/link";
import WalletAddress from "component/walletAddress"; import WalletAddress from "component/walletAddress";
import ShapeShift from "component/shapeShift";
const ReceiveCreditsPage = props => { const ReceiveCreditsPage = props => {
return ( return (
<main className="main--single-column"> <main className="main--single-column">
<SubHeader /> <SubHeader />
<WalletAddress /> <WalletAddress />
<ShapeShift />
<section className="card"> <section className="card">
<div className="card__title-primary"> <div className="card__title-primary">
<h3>{__("Where To Find Credits")}</h3> <h3>{__("More ways to get LBRY Credits")}</h3>
</div> </div>
<div className="card__content"> <div className="card__content">
<p> <p>

View file

@ -0,0 +1,137 @@
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// @flow
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
import Promise from "bluebird";
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
import * as types from "constants/action_types";
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
import { coinRegexPatterns } from "util/shape_shift";
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
import type {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
GetSupportedCoinsSuccess,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
GetCoinStatsStart,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
GetCoinStatsSuccess,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
GetCoinStatsFail,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
PrepareShapeShiftSuccess,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
PrepareShapeShiftFail,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
GetActiveShiftSuccess,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
GetActiveShiftFail,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
} from "redux/reducers/shape_shift";
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
import type { FormikActions } from "types/common";
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// use promise chains instead of callbacks for shapeshift api
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
const shapeShift = Promise.promisifyAll(require("shapeshift.io"));
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// All ShapeShift actions
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// Action types defined in the reducer will contain some payload
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
export type Action =
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| { type: types.GET_SUPPORTED_COINS_START }
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
liamcardenas commented 2017-12-04 21:19:17 +01:00 (Migrated from github.com)
Review

I get that you are defining these here so as not to create extra boilerplate work, but I wonder if all of the types should be defined in the same place? I think this is probably best, but I just wanted to throw this question out there in case anyone has any thoughts on it

I get that you are defining these here so as not to create extra boilerplate work, but I wonder if all of the types should be defined in the same place? I think this is probably best, but I just wanted to throw this question out there in case anyone has any thoughts on it
kauffj commented 2017-12-04 23:05:02 +01:00 (Migrated from github.com)
Review

My proposed design is:

  1. Add a types folder inside of js. types will eventually swallow constants.
  2. An Action type is defined in Action.js inside of this folder.
  3. This file also includes all action constant definitions.
  4. The Action type explicitly enumerates all possible action type values.

My biggest question about this design is whether there should only be one action type, or whether we should use subtypes for each possible action and payload signature.

My proposed design is: 1) Add a `types` folder inside of `js`. `types` will eventually swallow `constants`. 2) An `Action` type is defined in `Action.js` inside of this folder. 3) This file also includes all action constant definitions. 4) The `Action` type explicitly enumerates all possible action type values. My biggest question about this design is whether there should only be one action type, or whether we should use subtypes for each possible action and payload signature.
kauffj commented 2017-12-04 23:07:29 +01:00 (Migrated from github.com)
Review

Possibly better to discuss this here https://github.com/lbryio/lbry-app/issues/810

Possibly better to discuss this here https://github.com/lbryio/lbry-app/issues/810
kauffj commented 2017-12-04 23:07:46 +01:00 (Migrated from github.com)
Review

Let's not block this PR on getting action definition exactly correct.

Let's not block this PR on getting action definition exactly correct.
| { type: types.GET_SUPPORTED_COINS_FAIL }
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| GetSupportedCoinsSuccess
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| GetCoinStatsStart
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| { type: types.GET_COIN_STATS_START }
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| GetCoinStatsFail
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| GetCoinStatsSuccess
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| { type: types.PREPARE_SHAPE_SHIFT_START }
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| PrepareShapeShiftFail
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| PrepareShapeShiftSuccess
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| { type: types.GET_ACTIVE_SHIFT_START }
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| GetActiveShiftFail
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
| GetActiveShiftSuccess;
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// Basic thunk types
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// It would be nice to import these from types/common
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// Not sure how that would work since they rely on the Action type
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
type PromiseAction = Promise<Action>;
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
liamcardenas commented 2017-12-04 21:25:18 +01:00 (Migrated from github.com)
Review

can you make these generic and move them to a different folder as you alluded to in the comment? I also am not a huge fan of using the any type here but for now I think this is good.

i.e.

 type ThunkAction<T> = (dispatch: Dispatch<T>) => any;
 export type Dispatch<T> = (
   action: T | ThunkAction<T> | PromiseAction<T> | Array<T>
 ) => any;

can you make these generic and move them to a different folder as you alluded to in the comment? I also am not a huge fan of using the any type here but for now I think this is good. i.e. ```type PromiseAction<T> = Promise<T>; type ThunkAction<T> = (dispatch: Dispatch<T>) => any; export type Dispatch<T> = ( action: T | ThunkAction<T> | PromiseAction<T> | Array<T> ) => any;
liamcardenas commented 2017-12-04 21:26:20 +01:00 (Migrated from github.com)
Review

I don't want you to get bogged down with this if for some reason its really difficult

I don't want you to get bogged down with this if for some reason its really difficult
type ThunkAction = (dispatch: Dispatch) => any;
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
export type Dispatch = (
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
action: Action | ThunkAction | PromiseAction | Array<Action>
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
) => any;
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// ShapeShift form values
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
export type ShapeShiftFormValues = {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
originCoin: string,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
returnAddress: ?string,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
receiveAddress: string,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
};
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
export const shapeShiftInit = () => (dispatch: Dispatch): ThunkAction => {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({ type: types.GET_SUPPORTED_COINS_START });
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
return shapeShift
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.coinsAsync()
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.then(coinData => {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
let supportedCoins = [];
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
Object.keys(coinData).forEach(symbol => {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
if (coinData[symbol].status === "available") {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
supportedCoins.push(coinData[symbol]);
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
}
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
});
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// only use larger coins with client side validation
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
supportedCoins = supportedCoins
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.filter(coin => coinRegexPatterns[coin.symbol])
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.map(coin => coin.symbol);
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
type: types.GET_SUPPORTED_COINS_SUCCESS,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
data: supportedCoins,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
});
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch(getCoinStats(supportedCoins[0]));
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
})
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.catch(err =>
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({ type: types.GET_SUPPORTED_COINS_FAIL, data: err })
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
);
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
};
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
export const getCoinStats = (coin: string) => (
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch: Dispatch
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
): ThunkAction => {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
const pair = `${coin.toLowerCase()}_lbc`;
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({ type: types.GET_COIN_STATS_START, data: coin });
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
return shapeShift
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.marketInfoAsync(pair)
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.then(marketInfo =>
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({ type: types.GET_COIN_STATS_SUCCESS, data: marketInfo })
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
)
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.catch(err => dispatch({ type: types.GET_COIN_STATS_FAIL, data: err }));
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
};
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
export const createShapeShift = (
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
values: ShapeShiftFormValues,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
actions: FormikActions
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
) => (dispatch: Dispatch): ThunkAction => {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
const {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
originCoin,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
returnAddress,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
receiveAddress: withdrawalAddress,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
} = values;
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
const pair = `${originCoin.toLowerCase()}_lbc`;
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
const options = {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
returnAddress: returnAddress,
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
};
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({ type: types.PREPARE_SHAPE_SHIFT_START });
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
return shapeShift
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.shiftAsync(withdrawalAddress, pair, options)
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.then(res =>
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({ type: types.PREPARE_SHAPE_SHIFT_SUCCESS, data: res })
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
)
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.catch(err => {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({ type: types.PREPARE_SHAPE_SHIFT_FAIL, data: err });
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
// for formik to stop the submit
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
actions.setSubmitting(false);
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
});
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
};
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
export const getActiveShift = (depositAddress: string) => (
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch: Dispatch
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
): ThunkAction => {
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({ type: types.GET_ACTIVE_SHIFT_START });
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
return shapeShift
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.statusAsync(depositAddress)
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.then(res => dispatch({ type: types.GET_ACTIVE_SHIFT_SUCCESS, data: res }))
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
.catch(err => dispatch({ type: types.GET_ACTIVE_SHIFT_FAIL, data: err }));
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
};
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
export const clearShapeShift = () => (dispatch: Dispatch): Action =>
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added
dispatch({ type: types.CLEAR_SHAPE_SHIFT });
neb-b commented 2017-11-29 19:20:29 +01:00 (Migrated from github.com)
Review

whoops. added

whoops. added

View file

@ -0,0 +1,245 @@
// @flow
import { handleActions } from "util/redux-utils";
import * as actions from "constants/action_types";
import * as statuses from "constants/shape_shift";
export type ShapeShiftState = {
loading: boolean,
updating: boolean,
shiftSupportedCoins: Array<string>,
hasActiveShift: boolean,
originCoin: ?string,
error: ?string,
shiftDepositAddress: ?string,
shiftReturnAddress: ?string,
shiftCoinType: ?string,
shiftOrderId: ?string,
shiftState: ?string,
originCoinDepositMax: ?number,
// originCoinDepositMin is a string because we need to convert it from scientifc notation
// it will usually be something like 0.00000001 coins
// using Number(x) or parseInt(x) will either change it back to scientific notation or round to zero
originCoinDepositMin: ?string,
originCoinDepositFee: ?number,
shapeShiftRate: ?number,
};
// All ShapeShift actions that will have some payload
export type GetSupportedCoinsSuccess = {
type: actions.GET_SUPPORTED_COINS_SUCCESS,
data: Array<string>,
};
export type GetCoinStatsStart = {
type: actions.GET_SUPPORTED_COINS_SUCCESS,
data: string,
};
export type GetCoinStatsSuccess = {
type: actions.GET_COIN_STATS_SUCCESS,
data: ShapeShiftMarketInfo,
};
export type GetCoinStatsFail = {
type: actions.GET_COIN_STATS_FAIL,
data: string,
};
export type PrepareShapeShiftSuccess = {
type: actions.PREPARE_SHAPE_SHIFT_SUCCESS,
data: ActiveShiftInfo,
};
export type PrepareShapeShiftFail = {
type: actions.PREPARE_SHAPE_SHIFT_FAIL,
data: ShapeShiftErrorResponse,
};
export type GetActiveShiftSuccess = {
type: actions.GET_ACTIVE_SHIFT_SUCCESS,
data: string,
};
export type GetActiveShiftFail = {
type: actions.GET_ACTIVE_SHIFT_FAIL,
data: ShapeShiftErrorResponse,
};
// ShapeShift sub-types
// Defined for actions that contain an object in the payload
type ShapeShiftMarketInfo = {
limit: number,
minimum: number,
minerFee: number,
rate: number,
};
type ActiveShiftInfo = {
deposit: string,
depositType: string,
returnAddress: string,
orderId: string,
};
type ShapeShiftErrorResponse = {
message: string,
};
const defaultState: ShapeShiftState = {
loading: true,
updating: false,
shiftSupportedCoins: [],
hasActiveShift: false,
originCoin: undefined,
error: undefined,
shiftDepositAddress: undefined, // shapeshift address to send your coins to
shiftReturnAddress: undefined,
shiftCoinType: undefined,
shiftOrderId: undefined,
shiftState: undefined,
originCoinDepositMax: undefined,
originCoinDepositMin: undefined,
originCoinDepositFee: undefined,
shapeShiftRate: undefined,
};
export default handleActions(
{
[actions.GET_SUPPORTED_COINS_START]: (
state: ShapeShiftState
): ShapeShiftState => ({
...state,
loading: true,
error: undefined,
}),
[actions.GET_SUPPORTED_COINS_SUCCESS]: (
state: ShapeShiftState,
action: GetSupportedCoinsSuccess
): ShapeShiftState => {
const shiftSupportedCoins = action.data;
return {
...state,
error: undefined,
shiftSupportedCoins,
};
},
[actions.GET_SUPPORTED_COINS_FAIL]: (
state: ShapeShiftState
): ShapeShiftState => ({
...state,
loading: false,
error: "Error getting available coins",
}),
[actions.GET_COIN_STATS_START]: (
state: ShapeShiftState,
action: GetCoinStatsStart
): ShapeShiftState => {
const coin = action.data;
return {
...state,
updating: true,
originCoin: coin,
};
},
[actions.GET_COIN_STATS_SUCCESS]: (
state: ShapeShiftState,
action: GetCoinStatsSuccess
): ShapeShiftState => {
const marketInfo: ShapeShiftMarketInfo = action.data;
return {
...state,
loading: false,
updating: false,
originCoinDepositMax: marketInfo.limit,
// this will come in scientific notation
// toFixed shows the real number, then regex to remove trailing zeros
originCoinDepositMin: marketInfo.minimum
.toFixed(10)
.replace(/\.?0+$/, ""),
originCoinDepositFee: marketInfo.minerFee,
shapeShiftRate: marketInfo.rate,
};
},
[actions.GET_COIN_STATS_FAIL]: (
state: ShapeShiftState,
action: GetCoinStatsFail
): ShapeShiftState => {
const error = action.data;
return {
...state,
loading: false,
error,
};
},
[actions.PREPARE_SHAPE_SHIFT_START]: (
state: ShapeShiftState
): ShapeShiftState => ({
...state,
error: undefined,
}),
[actions.PREPARE_SHAPE_SHIFT_SUCCESS]: (
state: ShapeShiftState,
action: PrepareShapeShiftSuccess
) => {
const activeShiftInfo: ActiveShiftInfo = action.data;
return {
...state,
hasActiveShift: true,
shiftDepositAddress: activeShiftInfo.deposit,
shiftCoinType: activeShiftInfo.depositType,
shiftReturnAddress: activeShiftInfo.returnAddress,
shiftOrderId: activeShiftInfo.orderId,
shiftState: statuses.NO_DEPOSITS,
};
},
[actions.PREPARE_SHAPE_SHIFT_FAIL]: (
state: ShapeShiftState,
action: PrepareShapeShiftFail
) => {
const error: ShapeShiftErrorResponse = action.data;
return {
...state,
error: error.message,
};
},
[actions.CLEAR_SHAPE_SHIFT]: (state: ShapeShiftState): ShapeShiftState => ({
...state,
loading: false,
updating: false,
hasActiveShift: false,
shiftDepositAddress: undefined,
shiftReturnAddress: undefined,
shiftCoinType: undefined,
shiftOrderId: undefined,
originCoin: state.shiftSupportedCoins[0],
}),
[actions.GET_ACTIVE_SHIFT_START]: (
state: ShapeShiftState
): ShapeShiftState => ({
...state,
error: undefined,
updating: true,
}),
[actions.GET_ACTIVE_SHIFT_SUCCESS]: (
state: ShapeShiftState,
action: GetActiveShiftSuccess
): ShapeShiftState => {
const status = action.data;
return {
...state,
updating: false,
shiftState: status,
};
},
[actions.GET_ACTIVE_SHIFT_FAIL]: (
state: ShapeShiftState,
action: GetActiveShiftFail
): ShapeShiftState => {
const error: ShapeShiftErrorResponse = action.data;
return {
...state,
updating: false,
error: error.message,
};
},
},
defaultState
);

View file

@ -44,8 +44,8 @@ export const selectHeaderLinks = createSelector(selectCurrentPage, page => {
return { return {
wallet: __("Overview"), wallet: __("Overview"),
history: __("History"), history: __("History"),
send: __("Send"), send: __("Send Credits"),
receive: __("Receive"), receive: __("Get Credits"),
rewards: __("Rewards"), rewards: __("Rewards"),
invite: __("Invites"), invite: __("Invites"),
}; };
@ -78,9 +78,9 @@ export const selectPageTitle = createSelector(
case "wallet": case "wallet":
return __("Wallet"); return __("Wallet");
case "send": case "send":
return __("Send Credits"); return __("Send LBRY Credits");
case "receive": case "receive":
return __("Wallet Address"); return __("Get LBRY Credits");
case "backup": case "backup":
return __("Backup Your Wallet"); return __("Backup Your Wallet");
case "rewards": case "rewards":

View file

@ -65,7 +65,7 @@ export const selectWunderBarIcon = createSelector(
return "icon-envelope-open"; return "icon-envelope-open";
case "address": case "address":
case "receive": case "receive":
return "icon-address-book"; return "icon-credit-card";
case "wallet": case "wallet":
case "backup": case "backup":
return "icon-bank"; return "icon-bank";

View file

@ -0,0 +1,7 @@
import { createSelector } from "reselect";
const _selectState = state => state.shapeShift;
export const selectShapeShift = createSelector(_selectState, state => ({
...state,
}));

View file

@ -11,6 +11,7 @@ import searchReducer from "redux/reducers/search";
import settingsReducer from "redux/reducers/settings"; import settingsReducer from "redux/reducers/settings";
import userReducer from "redux/reducers/user"; import userReducer from "redux/reducers/user";
import walletReducer from "redux/reducers/wallet"; import walletReducer from "redux/reducers/wallet";
import shapeShiftReducer from "redux/reducers/shape_shift";
import { persistStore, autoRehydrate } from "redux-persist"; import { persistStore, autoRehydrate } from "redux-persist";
import createCompressor from "redux-persist-transform-compress"; import createCompressor from "redux-persist-transform-compress";
import createFilter from "redux-persist-transform-filter"; import createFilter from "redux-persist-transform-filter";
@ -67,6 +68,7 @@ const reducers = redux.combineReducers({
settings: settingsReducer, settings: settingsReducer,
wallet: walletReducer, wallet: walletReducer,
user: userReducer, user: userReducer,
shapeShift: shapeShiftReducer,
}); });
const bulkThunk = createBulkThunkMiddleware(); const bulkThunk = createBulkThunkMiddleware();

View file

@ -0,0 +1,3 @@
export type FormikActions = {
setSubmitting: boolean => mixed,
};

View file

@ -1,6 +1,7 @@
// util for creating reducers // util for creating reducers
// based off of redux-actions // based off of redux-actions
// https://redux-actions.js.org/docs/api/handleAction.html#handleactions // https://redux-actions.js.org/docs/api/handleAction.html#handleactions
export const handleActions = (actionMap, defaultState) => { export const handleActions = (actionMap, defaultState) => {
return (state = defaultState, action) => { return (state = defaultState, action) => {
const handler = actionMap[action.type]; const handler = actionMap[action.type];

View file

@ -0,0 +1,50 @@
// these don't need to be exact
// shapeshift does a more thourough check on validity
// just general matches to prevent unneccesary api calls
export const coinRegexPatterns = {
BTC: /^[13][a-km-zA-HJ-NP-Z1-9]{25,34}$/,
BCH: /^[13][a-km-zA-HJ-NP-Z1-9]{25,34}$/,
ETH: /^(0x)?[0-9a-fA-F]{40}$/,
DASH: /^X([0-9a-zA-Z]){33}/,
LTC: /^L[a-zA-Z0-9]{26,33}$/,
XMR: /^4[0-9ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]{94}$/,
};
const validateAddress = (coinType, address) => {
if (!coinType || !address) return false;
const coinRegex = coinRegexPatterns[coinType.toUpperCase()];
if (!coinRegex) return false;
return coinRegex.test(address);
};
export const validateShapeShiftForm = (vals, props) => {
let errors = {};
if (!vals.returnAddress) {
return errors;
}
const isValidAddress = validateAddress(vals.originCoin, vals.returnAddress);
if (!isValidAddress) {
errors.returnAddress = `Enter a valid ${vals.originCoin} address`;
}
return errors;
};
const exampleCoinAddresses = {
BTC: "1745oPaHeW7Fmpb1fUKTtasYfxr4zu9bwq",
BCH: "1745oPaHeW7Fmpb1fUKTtasYfxr4zu9bwq",
ETH: "0x8507cA6a274123fC8f80d929AF9D83602bC4e8cC",
DASH: "XedBP7vLPFXbS3URjrH2Z57Fg9SWftBmQ6",
LTC: "LgZivMvFMTDoqcA5weCQ2QrmRp7pa56bBk",
XMR:
"466XMeJEcowYGx7RzUJj3VDWBZgRWErVQQX6tHYbsacS5QF6v3tidE6LZZnTJgzeEh6bKEEJ6GC9jHirrUKvJwVKVj9e7jm",
};
export const getExampleAddress = coin => {
return exampleCoinAddresses[coin];
};

View file

@ -22,10 +22,14 @@
}, },
"homepage": "https://github.com/lbryio/lbry-app", "homepage": "https://github.com/lbryio/lbry-app",
"dependencies": { "dependencies": {
"bluebird": "^3.5.1",
"classnames": "^2.2.5",
"formik": "^0.10.4",
"from2": "^2.3.0", "from2": "^2.3.0",
"jshashes": "^1.0.7", "jshashes": "^1.0.7",
"localforage": "^1.5.0", "localforage": "^1.5.0",
"node-sass": "^4.5.3", "node-sass": "^4.5.3",
"qrcode.react": "^0.7.2",
"rc-progress": "^2.0.6", "rc-progress": "^2.0.6",
"react": "^16.2.0", "react": "^16.2.0",
"react-dom": "^16.2.0", "react-dom": "^16.2.0",
@ -43,6 +47,7 @@
"redux-thunk": "^2.2.0", "redux-thunk": "^2.2.0",
"render-media": "^2.10.0", "render-media": "^2.10.0",
"reselect": "^3.0.0", "reselect": "^3.0.0",
"shapeshift.io": "^1.3.1",
"y18n": "^3.2.1" "y18n": "^3.2.1"
}, },
"devDependencies": { "devDependencies": {

View file

@ -34,6 +34,11 @@ body
color: var(--color-meta-light); color: var(--color-meta-light);
} }
.credit-amount--bold
liamcardenas commented 2017-12-04 21:29:04 +01:00 (Migrated from github.com)
Review

is this used elsewhere in the app or is it just for shapeshift? I don't have a criticism here, I'm just wondering what we decided about using reusable vs case specific classes?

is this used elsewhere in the app or is it just for shapeshift? I don't have a criticism here, I'm just wondering what we decided about using reusable vs case specific classes?
{
font-weight: 700;
}
#main-content #main-content
{ {
margin: auto; margin: auto;

View file

@ -26,4 +26,6 @@
@import "component/_divider.scss"; @import "component/_divider.scss";
@import "component/_checkbox.scss"; @import "component/_checkbox.scss";
@import "component/_radio.scss"; @import "component/_radio.scss";
@import "component/_shapeshift.scss";
@import "component/_spinner.scss";
@import "page/_show.scss"; @import "page/_show.scss";

View file

@ -98,4 +98,4 @@ $button-focus-shift: 12%;
.button--submit { .button--submit {
font-family: inherit; font-family: inherit;
line-height: 0; line-height: 0;
} }

View file

@ -26,6 +26,7 @@
.card__actions { .card__actions {
padding: 0 var(--card-padding); padding: 0 var(--card-padding);
} }
.card--small { .card--small {
.card__title-primary, .card__title-primary,
.card__title-identity, .card__title-identity,
@ -50,7 +51,7 @@
.card__actions { .card__actions {
margin-top: var(--card-margin); margin-top: var(--card-margin);
margin-bottom: var(--card-margin); margin-bottom: var(--card-margin);
user-select: none; user-select: none;
} }
.card__actions--bottom { .card__actions--bottom {
@ -72,6 +73,18 @@
margin-bottom: var(--card-margin); margin-bottom: var(--card-margin);
} }
} }
.card__actions--only-vertical {
margin-left: 0;
margin-right: 0;
padding-left: 0;
padding-right: 0;
}
.card__content--extra-vertical-space {
margin: $spacing-vertical 0;
}
$font-size-subtext-multiple: 0.82; $font-size-subtext-multiple: 0.82;
.card__subtext { .card__subtext {
color: var(--color-meta-light); color: var(--color-meta-light);

View file

@ -56,6 +56,11 @@
padding-left: 5px; padding-left: 5px;
padding-right: 5px; padding-right: 5px;
width: 100%; width: 100%;
font-family: "Consolas", "Lucida Console", "Adobe Source Code Pro", monospace;
&.input-copyable--with-copy-btn {
width: 85%;
}
} }
input[readonly] { input[readonly] {

View file

@ -43,6 +43,8 @@
.wunderbar--active .icon-search { color: var(--color-primary); } .wunderbar--active .icon-search { color: var(--color-primary); }
// below styles should be inside the common input styling
// will come back to this with the redesign - sean
.wunderbar__input { .wunderbar__input {
background: var(--search-bg); background: var(--search-bg);
width: 100%; width: 100%;

View file

@ -0,0 +1,40 @@
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
// Can't think of a better way to do this
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
// The initial shapeshift form is 311px tall
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
// the .shapeshift__initial-wrapper class is only added when the form is being loaded
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
// Once the form is rendered, there is a very smooth transition because the height doesn't change
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
.shapeshift__wrapper.shapeshift__initial-wrapper {
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
min-height: 346px;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
}
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
.shapeshift__content {
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
.spinner {
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
margin-top: $spacing-vertical * 3;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
}
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
}
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
.shapeshift__tx-info {
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
min-height: 55px;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
neb-b commented 2017-12-04 17:41:12 +01:00 (Migrated from github.com)
Review

We would still need some sort of min height on that unless the heights are the same. I would rather not since this check is usually very quick and you would only see that for a small time before it goes back to the info text.

We would still need some sort of min height on that unless the heights are the same. I would rather not since this check is usually very quick and you would only see that for a small time before it goes back to the info text.
}
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
.shapeshift__deposit-address-wrapper {
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
display: flex;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
flex-direction: row;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
* {
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
align-self: center;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
}
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
}
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
// this should be pulled out into it's own styling when we add more qr codes
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
.shapeshift__qrcode {
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
// don't use a variable here. adds a white border for easier reading in dark mode
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
// needs to stay the same no matter what theme is present
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
background-color: #fff;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
padding: 2px;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
margin-left: 40px;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
}
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
.shapeshift__link {
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
padding-left: 10px;
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍
}
neb-b commented 2017-11-29 04:54:58 +01:00 (Migrated from github.com)
Review

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?

Don't need this class. The success class is just to add the green color on the text. There isn't any styles that only do that, maybe it should be a more generic className?
neb-b commented 2017-11-29 05:00:49 +01:00 (Migrated from github.com)
Review

Yeah...

Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered.

Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading

Yeah... Can't think of better way to do it. Nothing bad could really happen, at least nothing worse than not having this. If someone changes the form content to be a different height, it will just "jump" to that height after it's rendered. The same thing would happen if we don't have this style, it will "jump" and increase the height when the form is rendered. Happy to change it if we can think of a better way. I just hate having content jumping when stuff is loading
neb-b commented 2017-11-30 06:35:16 +01:00 (Migrated from github.com)
Review

I'll keep the min-height on shapeshift__maxdeposit to avoid content jumping when we fetch new max limits after the user changes the origin coin

I'll keep the min-height on `shapeshift__maxdeposit` to avoid content jumping when we fetch new max limits after the user changes the origin coin
neb-b commented 2017-11-30 06:40:25 +01:00 (Migrated from github.com)
Review

I don't think it's necessary to use the card-xx styles for this. It doesn't have anything to do with the card style. It's just a small bit of markup that needs some padding. I think ideally we could just use a s-vertical-padding helper class or something similar. We can discuss this more along with the display-xx helper classes.

I don't think it's necessary to use the `card-xx` styles for this. It doesn't have anything to do with the `card` style. It's just a small bit of markup that needs some padding. I think ideally we could just use a `s-vertical-padding` helper class or something similar. We can discuss this more along with the `display-xx` helper classes.
neb-b commented 2017-11-30 06:41:42 +01:00 (Migrated from github.com)
Review

👍

👍
kauffj commented 2017-11-30 17:47:48 +01:00 (Migrated from github.com)
Review

card__content is the class I'd propose using instead.

`card__content` is the class I'd propose using instead.
neb-b commented 2017-11-30 19:04:15 +01:00 (Migrated from github.com)
Review

👍

👍

View file

@ -0,0 +1,58 @@
.spinner {
position: relative;
width: 11em;
height: 11em;
margin: 20px auto;
font-size: 3px;
border-radius: 50%;
background: linear-gradient(to right, #fff 10%, rgba(255, 255, 255, 0) 50%);
animation: spin 1.4s infinite linear;
transform: translateZ(0);
@keyframes spin {
from {
transform: rotate(0deg);
}
to {
transform: rotate(360deg);
}
}
&:before,
&:after {
content: '';
position: absolute;
top: 0;
left: 0;
}
&:before {
width: 50%;
height: 50%;
background: #fff;
border-radius: 100% 0 0 0;
}
&:after {
height: 75%;
width: 75%;
margin: auto;
bottom: 0;
right: 0;
background: #000;
border-radius: 50%;
}
}
.spinner.spinner--dark {
background: linear-gradient(to right, var(--button-primary-bg) 10%, var(--color-bg) 50%);
&:before {
background: var(--button-primary-bg);
}
&:after {
background: var(--color-bg);
}
}

View file

@ -46,53 +46,6 @@ video {
align-items: center; align-items: center;
} }
.video__loading-spinner {
position: relative;
width: 11em;
height: 11em;
margin: 20px auto;
font-size: 3px;
border-radius: 50%;
background: linear-gradient(to right, #ffffff 10%, rgba(255, 255, 255, 0) 50%);
animation: spin 1.4s infinite linear;
transform: translateZ(0);
@keyframes spin {
from {
transform: rotate(0deg);
}
to {
transform: rotate(360deg);
}
}
&:before,
&:after {
content: '';
position: absolute;
top: 0;
left: 0;
}
&:before {
width: 50%;
height: 50%;
background: #ffffff;
border-radius: 100% 0 0 0;
}
&:after {
height: 75%;
width: 75%;
margin: auto;
bottom: 0;
right: 0;
background: black;
border-radius: 50%;
}
}
.video__loading-status { .video__loading-status {
padding-top: 20px; padding-top: 20px;
color: white; color: white;

View file

@ -18,7 +18,7 @@ module.exports = {
}, },
resolve: { resolve: {
modules: [appPath, "node_modules"], modules: [appPath, "node_modules"],
extensions: [".js", ".jsx", ".css"] extensions: [".js", ".jsx", ".css", ".json"]
}, },
neb-b commented 2017-12-04 04:39:49 +01:00 (Migrated from github.com)
Review

This is required because the shapeshift.io module has an import like const package = require('../package')

It causes the bundle to increase quite a bit. I will make a pr to that project to change it to const package = require('../package.json') which allow use to remove this

This is required because the shapeshift.io module has an import like `const package = require('../package')` It causes the bundle to increase quite a bit. I will make a pr to that project to change it to `const package = require('../package.json')` which allow use to remove this
module: { module: {
rules: [ rules: [

View file

@ -56,9 +56,9 @@ ajv@^4.7.0, ajv@^4.9.1:
co "^4.6.0" co "^4.6.0"
json-stable-stringify "^1.0.1" json-stable-stringify "^1.0.1"
ajv@^5.0.0, ajv@^5.1.5, ajv@^5.2.3: ajv@^5.0.0, ajv@^5.1.0, ajv@^5.1.5, ajv@^5.2.3:
version "5.4.0" version "5.5.0"
resolved "https://registry.yarnpkg.com/ajv/-/ajv-5.4.0.tgz#32d1cf08dbc80c432f426f12e10b2511f6b46474" resolved "https://registry.yarnpkg.com/ajv/-/ajv-5.5.0.tgz#eb2840746e9dc48bd5e063a36e3fd400c5eab5a9"
dependencies: dependencies:
co "^4.6.0" co "^4.6.0"
fast-deep-equal "^1.0.0" fast-deep-equal "^1.0.0"
@ -276,7 +276,11 @@ aws-sign2@~0.6.0:
version "0.6.0" version "0.6.0"
resolved "https://registry.yarnpkg.com/aws-sign2/-/aws-sign2-0.6.0.tgz#14342dd38dbcc94d0e5b87d763cd63612c0e794f" resolved "https://registry.yarnpkg.com/aws-sign2/-/aws-sign2-0.6.0.tgz#14342dd38dbcc94d0e5b87d763cd63612c0e794f"
aws4@^1.2.1: 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:
version "1.6.0" version "1.6.0"
resolved "https://registry.yarnpkg.com/aws4/-/aws4-1.6.0.tgz#83ef5ca860b2b32e4a0deedee8c771b9db57471e" resolved "https://registry.yarnpkg.com/aws4/-/aws4-1.6.0.tgz#83ef5ca860b2b32e4a0deedee8c771b9db57471e"
@ -997,6 +1001,10 @@ block-stream@*:
dependencies: dependencies:
inherits "~2.0.0" inherits "~2.0.0"
bluebird@^3.5.1:
version "3.5.1"
resolved "https://registry.yarnpkg.com/bluebird/-/bluebird-3.5.1.tgz#d9551f9de98f1fcda1e683d17ee91a0602ee2eb9"
bn.js@^4.0.0, bn.js@^4.1.0, bn.js@^4.1.1, bn.js@^4.4.0: bn.js@^4.0.0, bn.js@^4.1.0, bn.js@^4.1.1, bn.js@^4.4.0:
version "4.11.8" version "4.11.8"
resolved "https://registry.yarnpkg.com/bn.js/-/bn.js-4.11.8.tgz#2cde09eb5ee341f484746bb0309b3253b1b1442f" resolved "https://registry.yarnpkg.com/bn.js/-/bn.js-4.11.8.tgz#2cde09eb5ee341f484746bb0309b3253b1b1442f"
@ -1033,6 +1041,18 @@ boom@2.x.x:
dependencies: dependencies:
hoek "2.x.x" 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: brace-expansion@^1.1.7:
version "1.1.8" version "1.1.8"
resolved "https://registry.yarnpkg.com/brace-expansion/-/brace-expansion-1.1.8.tgz#c07b211c7c952ec1f8efd51a77ef0d1d3990a292" resolved "https://registry.yarnpkg.com/brace-expansion/-/brace-expansion-1.1.8.tgz#c07b211c7c952ec1f8efd51a77ef0d1d3990a292"
@ -1198,8 +1218,8 @@ caniuse-api@^1.5.2:
lodash.uniq "^4.5.0" lodash.uniq "^4.5.0"
caniuse-db@^1.0.30000529, caniuse-db@^1.0.30000634, caniuse-db@^1.0.30000639: caniuse-db@^1.0.30000529, caniuse-db@^1.0.30000634, caniuse-db@^1.0.30000639:
version "1.0.30000769" version "1.0.30000775"
resolved "https://registry.yarnpkg.com/caniuse-db/-/caniuse-db-1.0.30000769.tgz#c230b9c1b9e8db3e1c0d858c96e685741b96cc10" resolved "https://registry.yarnpkg.com/caniuse-db/-/caniuse-db-1.0.30000775.tgz#04bccdd0214edf25b97f61a096609f7ad6904333"
cardinal@^1.0.0: cardinal@^1.0.0:
version "1.0.0" version "1.0.0"
@ -1376,8 +1396,8 @@ codemirror-spell-checker@*:
typo-js "*" typo-js "*"
codemirror@*: codemirror@*:
version "5.31.0" version "5.32.0"
resolved "https://registry.yarnpkg.com/codemirror/-/codemirror-5.31.0.tgz#ecf3d057eb74174147066bfc7c5f37b4c4e07df2" resolved "https://registry.yarnpkg.com/codemirror/-/codemirror-5.32.0.tgz#cb6ff5d8ef36d0b10f031130e2d9ebeee92c902e"
color-convert@^1.3.0, color-convert@^1.9.0: color-convert@^1.3.0, color-convert@^1.9.0:
version "1.9.1" version "1.9.1"
@ -1426,8 +1446,8 @@ combined-stream@^1.0.5, combined-stream@~1.0.5:
delayed-stream "~1.0.0" delayed-stream "~1.0.0"
commander@^2.11.0, commander@^2.5.0, commander@^2.9.0: commander@^2.11.0, commander@^2.5.0, commander@^2.9.0:
version "2.11.0" version "2.12.2"
resolved "https://registry.yarnpkg.com/commander/-/commander-2.11.0.tgz#157152fd1e7a6c8d98a5b715cf376df928004563" resolved "https://registry.yarnpkg.com/commander/-/commander-2.12.2.tgz#0f5946c427ed9ec0d91a46bb9def53e54650e555"
commondir@^1.0.1: commondir@^1.0.1:
version "1.0.1" version "1.0.1"
@ -1525,8 +1545,8 @@ content-type@~1.0.4:
resolved "https://registry.yarnpkg.com/content-type/-/content-type-1.0.4.tgz#e138cc75e040c727b1966fe5e5f8c9aee256fe3b" resolved "https://registry.yarnpkg.com/content-type/-/content-type-1.0.4.tgz#e138cc75e040c727b1966fe5e5f8c9aee256fe3b"
convert-source-map@^1.5.0: convert-source-map@^1.5.0:
version "1.5.0" version "1.5.1"
resolved "https://registry.yarnpkg.com/convert-source-map/-/convert-source-map-1.5.0.tgz#9acd70851c6d5dfdd93d9282e5edf94a03ff46b5" resolved "https://registry.yarnpkg.com/convert-source-map/-/convert-source-map-1.5.1.tgz#b8278097b9bc229365de5c62cf5fcaed8b5599e5"
cookie-signature@1.0.6: cookie-signature@1.0.6:
version "1.0.6" version "1.0.6"
@ -1613,6 +1633,12 @@ cryptiles@2.x.x:
dependencies: dependencies:
boom "2.x.x" 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: crypto-browserify@3.3.0:
version "3.3.0" version "3.3.0"
resolved "https://registry.yarnpkg.com/crypto-browserify/-/crypto-browserify-3.3.0.tgz#b9fc75bb4a0ed61dcf1cd5dae96eb30c9c3e506c" resolved "https://registry.yarnpkg.com/crypto-browserify/-/crypto-browserify-3.3.0.tgz#b9fc75bb4a0ed61dcf1cd5dae96eb30c9c3e506c"
@ -1849,18 +1875,18 @@ detect-indent@^4.0.0:
repeating "^2.0.0" repeating "^2.0.0"
detect-libc@^1.0.2: detect-libc@^1.0.2:
version "1.0.2" version "1.0.3"
resolved "https://registry.yarnpkg.com/detect-libc/-/detect-libc-1.0.2.tgz#71ad5d204bf17a6a6ca8f450c61454066ef461e1" resolved "https://registry.yarnpkg.com/detect-libc/-/detect-libc-1.0.3.tgz#fa137c4bd698edf55cd5cd02ac559f91a4c4ba9b"
detect-node@^2.0.3: detect-node@^2.0.3:
version "2.0.3" version "2.0.3"
resolved "https://registry.yarnpkg.com/detect-node/-/detect-node-2.0.3.tgz#a2033c09cc8e158d37748fbde7507832bd6ce127" resolved "https://registry.yarnpkg.com/detect-node/-/detect-node-2.0.3.tgz#a2033c09cc8e158d37748fbde7507832bd6ce127"
detective@^4.3.1: detective@^4.3.1:
version "4.5.0" version "4.6.0"
resolved "https://registry.yarnpkg.com/detective/-/detective-4.5.0.tgz#6e5a8c6b26e6c7a254b1c6b6d7490d98ec91edd1" resolved "https://registry.yarnpkg.com/detective/-/detective-4.6.0.tgz#d1a793ad0bcc829fa225465061096b7bca040527"
dependencies: dependencies:
acorn "^4.0.3" acorn "^5.2.1"
defined "^1.0.0" defined "^1.0.0"
diffie-hellman@^5.0.0: diffie-hellman@^5.0.0:
@ -1896,11 +1922,14 @@ doctrine@1.5.0, doctrine@^1.2.2:
isarray "^1.0.0" isarray "^1.0.0"
doctrine@^2.0.0: doctrine@^2.0.0:
version "2.0.0" version "2.0.2"
resolved "https://registry.yarnpkg.com/doctrine/-/doctrine-2.0.0.tgz#c73d8d2909d22291e1a007a395804da8b665fe63" resolved "https://registry.yarnpkg.com/doctrine/-/doctrine-2.0.2.tgz#68f96ce8efc56cc42651f1faadb4f175273b0075"
dependencies: dependencies:
esutils "^2.0.2" esutils "^2.0.2"
isarray "^1.0.0"
dom-walk@^0.1.0:
version "0.1.1"
resolved "https://registry.yarnpkg.com/dom-walk/-/dom-walk-0.1.1.tgz#672226dc74c8f799ad35307df936aba11acd6018"
domain-browser@^1.1.1: domain-browser@^1.1.1:
version "1.1.7" version "1.1.7"
@ -2015,8 +2044,8 @@ error-ex@^1.2.0:
is-arrayish "^0.2.1" is-arrayish "^0.2.1"
es-abstract@^1.7.0: es-abstract@^1.7.0:
version "1.9.0" version "1.10.0"
resolved "https://registry.yarnpkg.com/es-abstract/-/es-abstract-1.9.0.tgz#690829a07cae36b222e7fd9b75c0d0573eb25227" resolved "https://registry.yarnpkg.com/es-abstract/-/es-abstract-1.10.0.tgz#1ecb36c197842a00d8ee4c2dfd8646bb97d60864"
dependencies: dependencies:
es-to-primitive "^1.1.1" es-to-primitive "^1.1.1"
function-bind "^1.1.1" function-bind "^1.1.1"
@ -2041,8 +2070,8 @@ es3ify@^0.1.3:
through "~2.3.4" through "~2.3.4"
es5-ext@^0.10.14, es5-ext@^0.10.35, es5-ext@^0.10.9, es5-ext@~0.10.14: es5-ext@^0.10.14, es5-ext@^0.10.35, es5-ext@^0.10.9, es5-ext@~0.10.14:
version "0.10.35" version "0.10.37"
resolved "https://registry.yarnpkg.com/es5-ext/-/es5-ext-0.10.35.tgz#18ee858ce6a3c45c7d79e91c15fcca9ec568494f" resolved "https://registry.yarnpkg.com/es5-ext/-/es5-ext-0.10.37.tgz#0ee741d148b80069ba27d020393756af257defc3"
dependencies: dependencies:
es6-iterator "~2.0.1" es6-iterator "~2.0.1"
es6-symbol "~3.1.1" es6-symbol "~3.1.1"
@ -2340,7 +2369,7 @@ expand-range@^1.8.1:
dependencies: dependencies:
fill-range "^2.1.0" fill-range "^2.1.0"
express@^4.13.3: express@^4.16.2:
version "4.16.2" version "4.16.2"
resolved "https://registry.yarnpkg.com/express/-/express-4.16.2.tgz#e35c6dfe2d64b7dca0a5cd4f21781be3299e076c" resolved "https://registry.yarnpkg.com/express/-/express-4.16.2.tgz#e35c6dfe2d64b7dca0a5cd4f21781be3299e076c"
dependencies: dependencies:
@ -2375,7 +2404,7 @@ express@^4.13.3:
utils-merge "1.0.1" utils-merge "1.0.1"
vary "~1.1.2" vary "~1.1.2"
extend@~3.0.0: extend@~3.0.0, extend@~3.0.1:
version "3.0.1" version "3.0.1"
resolved "https://registry.yarnpkg.com/extend/-/extend-3.0.1.tgz#a755ea7bc1adfcc5a31ce7e762dbaadc5e636444" resolved "https://registry.yarnpkg.com/extend/-/extend-3.0.1.tgz#a755ea7bc1adfcc5a31ce7e762dbaadc5e636444"
@ -2385,10 +2414,14 @@ extglob@^0.3.1:
dependencies: dependencies:
is-extglob "^1.0.0" is-extglob "^1.0.0"
extsprintf@1.3.0, extsprintf@^1.2.0: extsprintf@1.3.0:
version "1.3.0" version "1.3.0"
resolved "https://registry.yarnpkg.com/extsprintf/-/extsprintf-1.3.0.tgz#96918440e3041a7a414f8c52e3c574eb3c3e1e05" resolved "https://registry.yarnpkg.com/extsprintf/-/extsprintf-1.3.0.tgz#96918440e3041a7a414f8c52e3c574eb3c3e1e05"
extsprintf@^1.2.0:
version "1.4.0"
resolved "https://registry.yarnpkg.com/extsprintf/-/extsprintf-1.4.0.tgz#e2689f8f356fad62cca65a3a91c5df5f9551692f"
falafel@^1.0.1: falafel@^1.0.1:
version "1.2.0" version "1.2.0"
resolved "https://registry.yarnpkg.com/falafel/-/falafel-1.2.0.tgz#c18d24ef5091174a497f318cd24b026a25cddab4" resolved "https://registry.yarnpkg.com/falafel/-/falafel-1.2.0.tgz#c18d24ef5091174a497f318cd24b026a25cddab4"
@ -2567,6 +2600,12 @@ flow-typed@^2.2.3:
which "^1.2.14" which "^1.2.14"
yargs "^4.2.0" yargs "^4.2.0"
for-each@^0.3.2:
version "0.3.2"
resolved "https://registry.yarnpkg.com/for-each/-/for-each-0.3.2.tgz#2c40450b9348e97f281322593ba96704b9abd4d4"
dependencies:
is-function "~1.0.0"
for-in@^1.0.1: for-in@^1.0.1:
version "1.0.2" version "1.0.2"
resolved "https://registry.yarnpkg.com/for-in/-/for-in-1.0.2.tgz#81068d295a8142ec0ac726c6e2200c30fb6d5e80" resolved "https://registry.yarnpkg.com/for-in/-/for-in-1.0.2.tgz#81068d295a8142ec0ac726c6e2200c30fb6d5e80"
@ -2593,6 +2632,22 @@ form-data@~2.1.1:
combined-stream "^1.0.5" combined-stream "^1.0.5"
mime-types "^2.1.12" 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"
formik@^0.10.4:
version "0.10.5"
resolved "https://registry.yarnpkg.com/formik/-/formik-0.10.5.tgz#6984d2f22e918c6d2264a3cb86b8582f7277faca"
dependencies:
lodash.isequal "4.5.0"
prop-types "^15.5.10"
warning "^3.0.0"
forwarded@~0.1.2: forwarded@~0.1.2:
version "0.1.2" version "0.1.2"
resolved "https://registry.yarnpkg.com/forwarded/-/forwarded-0.1.2.tgz#98c23dab1175657b8c0573e8ceccd91b0ff18c84" resolved "https://registry.yarnpkg.com/forwarded/-/forwarded-0.1.2.tgz#98c23dab1175657b8c0573e8ceccd91b0ff18c84"
@ -2773,6 +2828,13 @@ glob@^7.0.0, glob@^7.0.3, glob@^7.0.5, glob@^7.1.1, glob@^7.1.2, glob@~7.1.1:
once "^1.3.0" once "^1.3.0"
path-is-absolute "^1.0.0" path-is-absolute "^1.0.0"
global@~4.3.0:
version "4.3.2"
resolved "https://registry.yarnpkg.com/global/-/global-4.3.2.tgz#e76989268a6c74c38908b1305b10fc0e394e9d0f"
dependencies:
min-document "^2.19.0"
process "~0.5.1"
globals@^9.14.0, globals@^9.18.0: globals@^9.14.0, globals@^9.18.0:
version "9.18.0" version "9.18.0"
resolved "https://registry.yarnpkg.com/globals/-/globals-9.18.0.tgz#aa3896b3e69b487f17e31ed2143d69a8e30c2d8a" resolved "https://registry.yarnpkg.com/globals/-/globals-9.18.0.tgz#aa3896b3e69b487f17e31ed2143d69a8e30c2d8a"
@ -2847,6 +2909,10 @@ har-schema@^1.0.5:
version "1.0.5" version "1.0.5"
resolved "https://registry.yarnpkg.com/har-schema/-/har-schema-1.0.5.tgz#d263135f43307c02c602afc8fe95970c0151369e" 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: har-validator@~2.0.6:
version "2.0.6" version "2.0.6"
resolved "https://registry.yarnpkg.com/har-validator/-/har-validator-2.0.6.tgz#cdcbc08188265ad119b6a5a7c8ab70eecfb5d27d" resolved "https://registry.yarnpkg.com/har-validator/-/har-validator-2.0.6.tgz#cdcbc08188265ad119b6a5a7c8ab70eecfb5d27d"
@ -2863,6 +2929,13 @@ har-validator@~4.2.1:
ajv "^4.9.1" ajv "^4.9.1"
har-schema "^1.0.5" 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: has-ansi@^2.0.0:
version "2.0.0" version "2.0.0"
resolved "https://registry.yarnpkg.com/has-ansi/-/has-ansi-2.0.0.tgz#34f5049ce1ecdf2b0649af3ef24e45ed35416d91" resolved "https://registry.yarnpkg.com/has-ansi/-/has-ansi-2.0.0.tgz#34f5049ce1ecdf2b0649af3ef24e45ed35416d91"
@ -2926,6 +2999,15 @@ hawk@3.1.3, hawk@~3.1.3:
hoek "2.x.x" hoek "2.x.x"
sntp "1.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: hmac-drbg@^1.0.0:
version "1.0.1" version "1.0.1"
resolved "https://registry.yarnpkg.com/hmac-drbg/-/hmac-drbg-1.0.1.tgz#d2745701025a6c775a6c545793ed502fc0c649a1" resolved "https://registry.yarnpkg.com/hmac-drbg/-/hmac-drbg-1.0.1.tgz#d2745701025a6c775a6c545793ed502fc0c649a1"
@ -2938,6 +3020,10 @@ hoek@2.x.x:
version "2.16.3" version "2.16.3"
resolved "https://registry.yarnpkg.com/hoek/-/hoek-2.16.3.tgz#20bb7403d3cea398e91dc4710a8ff1b8274a25ed" 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: hoist-non-react-statics@^2.2.1:
version "2.3.1" version "2.3.1"
resolved "https://registry.yarnpkg.com/hoist-non-react-statics/-/hoist-non-react-statics-2.3.1.tgz#343db84c6018c650778898240135a1420ee22ce0" resolved "https://registry.yarnpkg.com/hoist-non-react-statics/-/hoist-non-react-statics-2.3.1.tgz#343db84c6018c650778898240135a1420ee22ce0"
@ -3011,6 +3097,14 @@ http-signature@~1.1.0:
jsprim "^1.2.2" jsprim "^1.2.2"
sshpk "^1.7.0" 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: https-browserify@0.0.1:
version "0.0.1" version "0.0.1"
resolved "https://registry.yarnpkg.com/https-browserify/-/https-browserify-0.0.1.tgz#3f91365cabe60b77ed0ebba24b454e3e09d95a82" resolved "https://registry.yarnpkg.com/https-browserify/-/https-browserify-0.0.1.tgz#3f91365cabe60b77ed0ebba24b454e3e09d95a82"
@ -3151,8 +3245,8 @@ interpret@^0.6.4:
resolved "https://registry.yarnpkg.com/interpret/-/interpret-0.6.6.tgz#fecd7a18e7ce5ca6abfb953e1f86213a49f1625b" resolved "https://registry.yarnpkg.com/interpret/-/interpret-0.6.6.tgz#fecd7a18e7ce5ca6abfb953e1f86213a49f1625b"
interpret@^1.0.0: interpret@^1.0.0:
version "1.0.4" version "1.1.0"
resolved "https://registry.yarnpkg.com/interpret/-/interpret-1.0.4.tgz#820cdd588b868ffb191a809506d6c9c8f212b1b0" resolved "https://registry.yarnpkg.com/interpret/-/interpret-1.1.0.tgz#7ed1b1410c6a0e0f78cf95d3b8440c63f78b8614"
invariant@^2.0.0, invariant@^2.2.2: invariant@^2.0.0, invariant@^2.2.2:
version "2.2.2" version "2.2.2"
@ -3252,6 +3346,10 @@ is-fullwidth-code-point@^2.0.0:
version "2.0.0" version "2.0.0"
resolved "https://registry.yarnpkg.com/is-fullwidth-code-point/-/is-fullwidth-code-point-2.0.0.tgz#a3b30a5c4f199183167aaab93beefae3ddfb654f" resolved "https://registry.yarnpkg.com/is-fullwidth-code-point/-/is-fullwidth-code-point-2.0.0.tgz#a3b30a5c4f199183167aaab93beefae3ddfb654f"
is-function@^1.0.1, is-function@~1.0.0:
version "1.0.1"
resolved "https://registry.yarnpkg.com/is-function/-/is-function-1.0.1.tgz#12cfb98b65b57dd3d193a3121f5f6e2f437602b5"
is-glob@^2.0.0, is-glob@^2.0.1: is-glob@^2.0.0, is-glob@^2.0.1:
version "2.0.1" version "2.0.1"
resolved "https://registry.yarnpkg.com/is-glob/-/is-glob-2.0.1.tgz#d096f926a3ded5600f3fdfd91198cb0888c2d863" resolved "https://registry.yarnpkg.com/is-glob/-/is-glob-2.0.1.tgz#d096f926a3ded5600f3fdfd91198cb0888c2d863"
@ -3300,8 +3398,8 @@ is-path-in-cwd@^1.0.0:
is-path-inside "^1.0.0" is-path-inside "^1.0.0"
is-path-inside@^1.0.0: is-path-inside@^1.0.0:
version "1.0.0" version "1.0.1"
resolved "https://registry.yarnpkg.com/is-path-inside/-/is-path-inside-1.0.0.tgz#fc06e5a1683fbda13de667aff717bbc10a48f37f" resolved "https://registry.yarnpkg.com/is-path-inside/-/is-path-inside-1.0.1.tgz#8ef5b7de50437a3fdca6b4e865ef7aa55cb48036"
dependencies: dependencies:
path-is-inside "^1.0.1" path-is-inside "^1.0.1"
@ -3404,8 +3502,8 @@ isurl@^1.0.0-alpha5:
is-object "^1.0.1" is-object "^1.0.1"
js-base64@^2.1.8, js-base64@^2.1.9: js-base64@^2.1.8, js-base64@^2.1.9:
version "2.3.2" version "2.4.0"
resolved "https://registry.yarnpkg.com/js-base64/-/js-base64-2.3.2.tgz#a79a923666372b580f8e27f51845c6f7e8fbfbaf" resolved "https://registry.yarnpkg.com/js-base64/-/js-base64-2.4.0.tgz#9e566fee624751a1d720c966cd6226d29d4025aa"
js-tokens@^3.0.0, js-tokens@^3.0.2: js-tokens@^3.0.0, js-tokens@^3.0.2:
version "3.0.2" version "3.0.2"
@ -3673,8 +3771,8 @@ loader-utils@^1.0.2, loader-utils@^1.1.0:
json5 "^0.5.0" json5 "^0.5.0"
localforage@^1.5.0: localforage@^1.5.0:
version "1.5.3" version "1.5.5"
resolved "https://registry.yarnpkg.com/localforage/-/localforage-1.5.3.tgz#698aa16af1022340b240be9d93192e8af022ff16" resolved "https://registry.yarnpkg.com/localforage/-/localforage-1.5.5.tgz#55fc1c3a88a47f67f5fac6f1231b25ff13556423"
dependencies: dependencies:
lie "3.0.2" lie "3.0.2"
@ -3778,6 +3876,10 @@ lodash.isempty@^4.4.0:
version "4.4.0" version "4.4.0"
resolved "https://registry.yarnpkg.com/lodash.isempty/-/lodash.isempty-4.4.0.tgz#6f86cbedd8be4ec987be9aaf33c9684db1b31e7e" resolved "https://registry.yarnpkg.com/lodash.isempty/-/lodash.isempty-4.4.0.tgz#6f86cbedd8be4ec987be9aaf33c9684db1b31e7e"
lodash.isequal@4.5.0:
version "4.5.0"
resolved "https://registry.yarnpkg.com/lodash.isequal/-/lodash.isequal-4.5.0.tgz#415c4478f2bcc30120c22ce10ed3226f7d3e18e0"
lodash.isplainobject@^4.0.6: lodash.isplainobject@^4.0.6:
version "4.0.6" version "4.0.6"
resolved "https://registry.yarnpkg.com/lodash.isplainobject/-/lodash.isplainobject-4.0.6.tgz#7c526a52d89b45c45cc690b88163be0497f550cb" resolved "https://registry.yarnpkg.com/lodash.isplainobject/-/lodash.isplainobject-4.0.6.tgz#7c526a52d89b45c45cc690b88163be0497f550cb"
@ -4017,7 +4119,11 @@ miller-rabin@^4.0.0:
bn.js "^4.0.0" bn.js "^4.0.0"
brorand "^1.0.1" brorand "^1.0.1"
"mime-db@>= 1.30.0 < 2", mime-db@~1.30.0: "mime-db@>= 1.30.0 < 2":
version "1.32.0"
resolved "https://registry.yarnpkg.com/mime-db/-/mime-db-1.32.0.tgz#485b3848b01a3cda5f968b4882c0771e58e09414"
mime-db@~1.30.0:
version "1.30.0" version "1.30.0"
resolved "https://registry.yarnpkg.com/mime-db/-/mime-db-1.30.0.tgz#74c643da2dd9d6a45399963465b26d5ca7d71f01" resolved "https://registry.yarnpkg.com/mime-db/-/mime-db-1.30.0.tgz#74c643da2dd9d6a45399963465b26d5ca7d71f01"
@ -4027,10 +4133,14 @@ mime-types@^2.1.12, mime-types@~2.1.15, mime-types@~2.1.16, mime-types@~2.1.17,
dependencies: dependencies:
mime-db "~1.30.0" mime-db "~1.30.0"
mime@1.4.1, mime@^1.2.11, mime@^1.3.4: mime@1.4.1:
version "1.4.1" version "1.4.1"
resolved "https://registry.yarnpkg.com/mime/-/mime-1.4.1.tgz#121f9ebc49e3766f311a76e1fa1c8003c4b03aa6" resolved "https://registry.yarnpkg.com/mime/-/mime-1.4.1.tgz#121f9ebc49e3766f311a76e1fa1c8003c4b03aa6"
mime@^1.2.11, mime@^1.5.0:
version "1.6.0"
resolved "https://registry.yarnpkg.com/mime/-/mime-1.6.0.tgz#32cd9e5c64553bd58d19a568af452acff04981b1"
mimic-fn@^1.0.0: mimic-fn@^1.0.0:
version "1.1.0" version "1.1.0"
resolved "https://registry.yarnpkg.com/mimic-fn/-/mimic-fn-1.1.0.tgz#e667783d92e89dbd342818b5230b9d62a672ad18" resolved "https://registry.yarnpkg.com/mimic-fn/-/mimic-fn-1.1.0.tgz#e667783d92e89dbd342818b5230b9d62a672ad18"
@ -4039,6 +4149,12 @@ mimic-response@^1.0.0:
version "1.0.0" version "1.0.0"
resolved "https://registry.yarnpkg.com/mimic-response/-/mimic-response-1.0.0.tgz#df3d3652a73fded6b9b0b24146e6fd052353458e" resolved "https://registry.yarnpkg.com/mimic-response/-/mimic-response-1.0.0.tgz#df3d3652a73fded6b9b0b24146e6fd052353458e"
min-document@^2.19.0:
version "2.19.0"
resolved "https://registry.yarnpkg.com/min-document/-/min-document-2.19.0.tgz#7bd282e3f5842ed295bb748cdd9f1ffa2c824685"
dependencies:
dom-walk "^0.1.0"
minimalistic-assert@^1.0.0: minimalistic-assert@^1.0.0:
version "1.0.0" version "1.0.0"
resolved "https://registry.yarnpkg.com/minimalistic-assert/-/minimalistic-assert-1.0.0.tgz#702be2dda6b37f4836bcb3f5db56641b64a1d3d3" resolved "https://registry.yarnpkg.com/minimalistic-assert/-/minimalistic-assert-1.0.0.tgz#702be2dda6b37f4836bcb3f5db56641b64a1d3d3"
@ -4053,7 +4169,7 @@ minimalistic-crypto-utils@^1.0.0, minimalistic-crypto-utils@^1.0.1:
dependencies: dependencies:
brace-expansion "^1.1.7" brace-expansion "^1.1.7"
minimist@0.0.8, minimist@~0.0.1: minimist@0.0.8:
version "0.0.8" version "0.0.8"
resolved "https://registry.yarnpkg.com/minimist/-/minimist-0.0.8.tgz#857fcabfc3397d2625b8228262e86aa7a011b05d" resolved "https://registry.yarnpkg.com/minimist/-/minimist-0.0.8.tgz#857fcabfc3397d2625b8228262e86aa7a011b05d"
@ -4061,6 +4177,10 @@ minimist@^1.1.1, minimist@^1.1.3, minimist@^1.2.0:
version "1.2.0" version "1.2.0"
resolved "https://registry.yarnpkg.com/minimist/-/minimist-1.2.0.tgz#a35008b20f41383eec1fb914f4cd5df79a264284" 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, 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" version "0.5.1"
resolved "https://registry.yarnpkg.com/mkdirp/-/mkdirp-0.5.1.tgz#30057438eac6cf7f8c4767f38648d6697d75c903" resolved "https://registry.yarnpkg.com/mkdirp/-/mkdirp-0.5.1.tgz#30057438eac6cf7f8c4767f38648d6697d75c903"
@ -4091,8 +4211,8 @@ multicast-dns-service-types@^1.1.0:
resolved "https://registry.yarnpkg.com/multicast-dns-service-types/-/multicast-dns-service-types-1.1.0.tgz#899f11d9686e5e05cb91b35d5f0e63b773cfc901" resolved "https://registry.yarnpkg.com/multicast-dns-service-types/-/multicast-dns-service-types-1.1.0.tgz#899f11d9686e5e05cb91b35d5f0e63b773cfc901"
multicast-dns@^6.0.1: multicast-dns@^6.0.1:
version "6.2.0" version "6.2.1"
resolved "https://registry.yarnpkg.com/multicast-dns/-/multicast-dns-6.2.0.tgz#13f22d0c32dc5ee82a32878e3c380d875b3eab22" resolved "https://registry.yarnpkg.com/multicast-dns/-/multicast-dns-6.2.1.tgz#c5035defa9219d30640558a49298067352098060"
dependencies: dependencies:
dns-packet "^1.0.1" dns-packet "^1.0.1"
thunky "^0.1.0" thunky "^0.1.0"
@ -4363,7 +4483,7 @@ number-is-nan@^1.0.0:
version "1.0.1" version "1.0.1"
resolved "https://registry.yarnpkg.com/number-is-nan/-/number-is-nan-1.0.1.tgz#097b602b53422a522c1afb8790318336941a011d" 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.1, oauth-sign@~0.8.2:
version "0.8.2" version "0.8.2"
resolved "https://registry.yarnpkg.com/oauth-sign/-/oauth-sign-0.8.2.tgz#46a6ab7f0aead8deae9ec0565780b7d4efeb9d43" resolved "https://registry.yarnpkg.com/oauth-sign/-/oauth-sign-0.8.2.tgz#46a6ab7f0aead8deae9ec0565780b7d4efeb9d43"
@ -4580,6 +4700,13 @@ parse-glob@^3.0.4:
is-extglob "^1.0.0" is-extglob "^1.0.0"
is-glob "^2.0.0" is-glob "^2.0.0"
parse-headers@^2.0.0:
version "2.0.1"
resolved "https://registry.yarnpkg.com/parse-headers/-/parse-headers-2.0.1.tgz#6ae83a7aa25a9d9b700acc28698cd1f1ed7e9536"
dependencies:
for-each "^0.3.2"
trim "0.0.1"
parse-json@^2.2.0: parse-json@^2.2.0:
version "2.2.0" version "2.2.0"
resolved "https://registry.yarnpkg.com/parse-json/-/parse-json-2.2.0.tgz#f480f40434ef80741f8469099f8dea18f55a4dc9" resolved "https://registry.yarnpkg.com/parse-json/-/parse-json-2.2.0.tgz#f480f40434ef80741f8469099f8dea18f55a4dc9"
@ -4660,6 +4787,10 @@ performance-now@^0.2.0:
version "0.2.0" version "0.2.0"
resolved "https://registry.yarnpkg.com/performance-now/-/performance-now-0.2.0.tgz#33ef30c5c77d4ea21c5a53869d91b56d8f2555e5" 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: pify@^2.0.0:
version "2.3.0" version "2.3.0"
resolved "https://registry.yarnpkg.com/pify/-/pify-2.3.0.tgz#ed141a6ac043a849ea588498e7dca8b15330e90c" resolved "https://registry.yarnpkg.com/pify/-/pify-2.3.0.tgz#ed141a6ac043a849ea588498e7dca8b15330e90c"
@ -4976,6 +5107,10 @@ process@^0.11.0, process@^0.11.10:
version "0.11.10" version "0.11.10"
resolved "https://registry.yarnpkg.com/process/-/process-0.11.10.tgz#7332300e840161bda3e69a1d1d91a7d4bc16f182" resolved "https://registry.yarnpkg.com/process/-/process-0.11.10.tgz#7332300e840161bda3e69a1d1d91a7d4bc16f182"
process@~0.5.1:
version "0.5.2"
resolved "https://registry.yarnpkg.com/process/-/process-0.5.2.tgz#1638d8a8e34c2f440a91db95ab9aeb677fc185cf"
progress@^1.1.8: progress@^1.1.8:
version "1.1.8" version "1.1.8"
resolved "https://registry.yarnpkg.com/progress/-/progress-1.1.8.tgz#e260c78f6161cdd9b0e56cc3e0a85de17c7a57be" resolved "https://registry.yarnpkg.com/progress/-/progress-1.1.8.tgz#e260c78f6161cdd9b0e56cc3e0a85de17c7a57be"
@ -5047,7 +5182,18 @@ q@^1.1.2:
version "1.5.1" version "1.5.1"
resolved "https://registry.yarnpkg.com/q/-/q-1.5.1.tgz#7e32f75b41381291d04611f1bf14109ac00651d7" resolved "https://registry.yarnpkg.com/q/-/q-1.5.1.tgz#7e32f75b41381291d04611f1bf14109ac00651d7"
qs@6.5.1: qr.js@0.0.0:
version "0.0.0"
resolved "https://registry.yarnpkg.com/qr.js/-/qr.js-0.0.0.tgz#cace86386f59a0db8050fa90d9b6b0e88a1e364f"
qrcode.react@^0.7.2:
version "0.7.2"
resolved "https://registry.yarnpkg.com/qrcode.react/-/qrcode.react-0.7.2.tgz#72a5718fd56baafe15c2c153fe436628d83aa286"
dependencies:
prop-types "^15.5.8"
qr.js "0.0.0"
qs@6.5.1, qs@~6.5.1:
version "6.5.1" version "6.5.1"
resolved "https://registry.yarnpkg.com/qs/-/qs-6.5.1.tgz#349cdf6eef89ec45c12d7d5eb3fc0c870343a6d8" resolved "https://registry.yarnpkg.com/qs/-/qs-6.5.1.tgz#349cdf6eef89ec45c12d7d5eb3fc0c870343a6d8"
@ -5123,8 +5269,8 @@ raw-body@2.3.2:
unpipe "1.0.0" unpipe "1.0.0"
rc-progress@^2.0.6: rc-progress@^2.0.6:
version "2.2.4" version "2.2.5"
resolved "https://registry.yarnpkg.com/rc-progress/-/rc-progress-2.2.4.tgz#45dbdb91cdd71cb5ce22e61313a351ceb5b1488a" resolved "https://registry.yarnpkg.com/rc-progress/-/rc-progress-2.2.5.tgz#e61d0544bf9d4208e5ba32fc50962159e7f952a3"
dependencies: dependencies:
babel-runtime "6.x" babel-runtime "6.x"
prop-types "^15.5.8" prop-types "^15.5.8"
@ -5164,11 +5310,12 @@ react-markdown@^2.5.0:
prop-types "^15.5.1" prop-types "^15.5.1"
react-modal@^3.1.5: react-modal@^3.1.5:
version "3.1.5" version "3.1.6"
resolved "https://registry.yarnpkg.com/react-modal/-/react-modal-3.1.5.tgz#9cfdb7634b5003148ffb7c8ead13a36f671d744e" resolved "https://registry.yarnpkg.com/react-modal/-/react-modal-3.1.6.tgz#82e63f1ec86b80e242518250d066ee37fa035f8a"
dependencies: dependencies:
exenv "^1.2.0" exenv "^1.2.0"
prop-types "^15.5.10" prop-types "^15.5.10"
warning "^3.0.0"
react-paginate@^5.0.0: react-paginate@^5.0.0:
version "5.0.0" version "5.0.0"
@ -5460,32 +5607,34 @@ repeating@^2.0.0:
dependencies: dependencies:
is-finite "^1.0.0" is-finite "^1.0.0"
request@2, request@~2.79.0: request@2, request@^2.55.0, request@^2.81.0:
version "2.79.0" version "2.83.0"
resolved "https://registry.yarnpkg.com/request/-/request-2.79.0.tgz#4dfe5bf6be8b8cdc37fcf93e04b65577722710de" resolved "https://registry.yarnpkg.com/request/-/request-2.83.0.tgz#ca0b65da02ed62935887808e6f510381034e3356"
dependencies: dependencies:
aws-sign2 "~0.6.0" aws-sign2 "~0.7.0"
aws4 "^1.2.1" aws4 "^1.6.0"
caseless "~0.11.0" caseless "~0.12.0"
combined-stream "~1.0.5" combined-stream "~1.0.5"
extend "~3.0.0" extend "~3.0.1"
forever-agent "~0.6.1" forever-agent "~0.6.1"
form-data "~2.1.1" form-data "~2.3.1"
har-validator "~2.0.6" har-validator "~5.0.3"
hawk "~3.1.3" hawk "~6.0.2"
http-signature "~1.1.0" http-signature "~1.2.0"
is-typedarray "~1.0.0" is-typedarray "~1.0.0"
isstream "~0.1.2" isstream "~0.1.2"
json-stringify-safe "~5.0.1" json-stringify-safe "~5.0.1"
mime-types "~2.1.7" mime-types "~2.1.17"
oauth-sign "~0.8.1" oauth-sign "~0.8.2"
qs "~6.3.0" performance-now "^2.1.0"
stringstream "~0.0.4" qs "~6.5.1"
tough-cookie "~2.3.0" safe-buffer "^5.1.1"
tunnel-agent "~0.4.1" stringstream "~0.0.5"
uuid "^3.0.0" tough-cookie "~2.3.3"
tunnel-agent "^0.6.0"
uuid "^3.1.0"
request@2.81.0, request@^2.81.0: request@2.81.0:
version "2.81.0" version "2.81.0"
resolved "https://registry.yarnpkg.com/request/-/request-2.81.0.tgz#c6928946a0e06c5f8d6f8a9333469ffda46298a0" resolved "https://registry.yarnpkg.com/request/-/request-2.81.0.tgz#c6928946a0e06c5f8d6f8a9333469ffda46298a0"
dependencies: dependencies:
@ -5512,6 +5661,31 @@ request@2.81.0, request@^2.81.0:
tunnel-agent "^0.6.0" tunnel-agent "^0.6.0"
uuid "^3.0.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: require-directory@^2.1.1:
version "2.1.1" version "2.1.1"
resolved "https://registry.yarnpkg.com/require-directory/-/require-directory-2.1.1.tgz#8c64ad5fd30dab1c976e2344ffe7f792a6a6df42" resolved "https://registry.yarnpkg.com/require-directory/-/require-directory-2.1.1.tgz#8c64ad5fd30dab1c976e2344ffe7f792a6a6df42"
@ -5730,6 +5904,13 @@ sha.js@^2.4.0, sha.js@^2.4.8:
inherits "^2.0.1" inherits "^2.0.1"
safe-buffer "^5.0.1" safe-buffer "^5.0.1"
shapeshift.io@^1.3.1:
version "1.3.1"
resolved "https://registry.yarnpkg.com/shapeshift.io/-/shapeshift.io-1.3.1.tgz#939f7d89e6a93fad4b556567d3fcdab45d5cc021"
dependencies:
request "^2.55.0"
xhr "^2.0.1"
shebang-command@^1.2.0: shebang-command@^1.2.0:
version "1.2.0" version "1.2.0"
resolved "https://registry.yarnpkg.com/shebang-command/-/shebang-command-1.2.0.tgz#44aac65b695b03398968c39f363fee5deafdf1ea" resolved "https://registry.yarnpkg.com/shebang-command/-/shebang-command-1.2.0.tgz#44aac65b695b03398968c39f363fee5deafdf1ea"
@ -5790,6 +5971,12 @@ sntp@1.x.x:
dependencies: dependencies:
hoek "2.x.x" 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: sockjs-client@1.1.4:
version "1.1.4" version "1.1.4"
resolved "https://registry.yarnpkg.com/sockjs-client/-/sockjs-client-1.1.4.tgz#5babe386b775e4cf14e7520911452654016c8b12" resolved "https://registry.yarnpkg.com/sockjs-client/-/sockjs-client-1.1.4.tgz#5babe386b775e4cf14e7520911452654016c8b12"
@ -5915,7 +6102,11 @@ staged-git-files@0.0.4:
version "0.0.4" version "0.0.4"
resolved "https://registry.yarnpkg.com/staged-git-files/-/staged-git-files-0.0.4.tgz#d797e1b551ca7a639dec0237dc6eb4bb9be17d35" resolved "https://registry.yarnpkg.com/staged-git-files/-/staged-git-files-0.0.4.tgz#d797e1b551ca7a639dec0237dc6eb4bb9be17d35"
"statuses@>= 1.3.1 < 2", statuses@~1.3.1: "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:
version "1.3.1" version "1.3.1"
resolved "https://registry.yarnpkg.com/statuses/-/statuses-1.3.1.tgz#faf51b9eb74aaef3b3acf4ad5f61abf24cb7b93e" resolved "https://registry.yarnpkg.com/statuses/-/statuses-1.3.1.tgz#faf51b9eb74aaef3b3acf4ad5f61abf24cb7b93e"
@ -5991,7 +6182,7 @@ string_decoder@^1.0.0, string_decoder@~1.0.3:
dependencies: dependencies:
safe-buffer "~5.1.0" safe-buffer "~5.1.0"
stringstream@~0.0.4: stringstream@~0.0.4, stringstream@~0.0.5:
version "0.0.5" version "0.0.5"
resolved "https://registry.yarnpkg.com/stringstream/-/stringstream-0.0.5.tgz#4e484cd4de5a0bbbee18e46307710a8a81621878" resolved "https://registry.yarnpkg.com/stringstream/-/stringstream-0.0.5.tgz#4e484cd4de5a0bbbee18e46307710a8a81621878"
@ -6067,8 +6258,8 @@ svgo@^0.7.0:
whet.extend "~0.9.9" whet.extend "~0.9.9"
symbol-observable@^1.0.1, symbol-observable@^1.0.3: symbol-observable@^1.0.1, symbol-observable@^1.0.3:
version "1.0.4" version "1.1.0"
resolved "https://registry.yarnpkg.com/symbol-observable/-/symbol-observable-1.0.4.tgz#29bf615d4aa7121bdd898b22d4b3f9bc4e2aa03d" resolved "https://registry.yarnpkg.com/symbol-observable/-/symbol-observable-1.1.0.tgz#5c68fd8d54115d9dfb72a84720549222e8db9b32"
table@^3.7.8: table@^3.7.8:
version "3.8.3" version "3.8.3"
@ -6162,7 +6353,7 @@ to-fast-properties@^1.0.3:
version "1.0.3" version "1.0.3"
resolved "https://registry.yarnpkg.com/to-fast-properties/-/to-fast-properties-1.0.3.tgz#b83571fa4d8c25b82e231b06e3a3055de4ca1a47" 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.0, tough-cookie@~2.3.3:
version "2.3.3" version "2.3.3"
resolved "https://registry.yarnpkg.com/tough-cookie/-/tough-cookie-2.3.3.tgz#0b618a5565b6dea90bf3425d04d55edc475a7561" resolved "https://registry.yarnpkg.com/tough-cookie/-/tough-cookie-2.3.3.tgz#0b618a5565b6dea90bf3425d04d55edc475a7561"
dependencies: dependencies:
@ -6180,6 +6371,10 @@ trim-right@^1.0.1:
version "1.0.1" version "1.0.1"
resolved "https://registry.yarnpkg.com/trim-right/-/trim-right-1.0.1.tgz#cb2e1203067e0c8de1f614094b9fe45704ea6003" resolved "https://registry.yarnpkg.com/trim-right/-/trim-right-1.0.1.tgz#cb2e1203067e0c8de1f614094b9fe45704ea6003"
trim@0.0.1:
version "0.0.1"
resolved "https://registry.yarnpkg.com/trim/-/trim-0.0.1.tgz#5858547f6b290757ee95cccc666fb50084c460dd"
"true-case-path@^1.0.2": "true-case-path@^1.0.2":
version "1.0.2" version "1.0.2"
resolved "https://registry.yarnpkg.com/true-case-path/-/true-case-path-1.0.2.tgz#7ec91130924766c7f573be3020c34f8fdfd00d62" resolved "https://registry.yarnpkg.com/true-case-path/-/true-case-path-1.0.2.tgz#7ec91130924766c7f573be3020c34f8fdfd00d62"
@ -6371,7 +6566,7 @@ uuid@^2.0.2:
version "2.0.3" version "2.0.3"
resolved "https://registry.yarnpkg.com/uuid/-/uuid-2.0.3.tgz#67e2e863797215530dff318e5bf9dcebfd47b21a" resolved "https://registry.yarnpkg.com/uuid/-/uuid-2.0.3.tgz#67e2e863797215530dff318e5bf9dcebfd47b21a"
uuid@^3.0.0: uuid@^3.0.0, uuid@^3.1.0:
version "3.1.0" version "3.1.0"
resolved "https://registry.yarnpkg.com/uuid/-/uuid-3.1.0.tgz#3dd3d3e790abc24d7b0d3a034ffababe28ebbc04" resolved "https://registry.yarnpkg.com/uuid/-/uuid-3.1.0.tgz#3dd3d3e790abc24d7b0d3a034ffababe28ebbc04"
@ -6423,6 +6618,12 @@ vm-browserify@0.0.4:
dependencies: dependencies:
indexof "0.0.1" indexof "0.0.1"
warning@^3.0.0:
version "3.0.0"
resolved "https://registry.yarnpkg.com/warning/-/warning-3.0.0.tgz#32e5377cb572de4ab04753bdf8821c01ed605b7c"
dependencies:
loose-envify "^1.0.0"
watchpack@^0.2.1: watchpack@^0.2.1:
version "0.2.9" version "0.2.9"
resolved "https://registry.yarnpkg.com/watchpack/-/watchpack-0.2.9.tgz#62eaa4ab5e5ba35fdfc018275626e3c0f5e3fb0b" resolved "https://registry.yarnpkg.com/watchpack/-/watchpack-0.2.9.tgz#62eaa4ab5e5ba35fdfc018275626e3c0f5e3fb0b"
@ -6453,18 +6654,18 @@ webpack-core@~0.6.9:
source-map "~0.4.1" source-map "~0.4.1"
webpack-dev-middleware@^1.11.0: webpack-dev-middleware@^1.11.0:
version "1.12.0" version "1.12.2"
resolved "https://registry.yarnpkg.com/webpack-dev-middleware/-/webpack-dev-middleware-1.12.0.tgz#d34efefb2edda7e1d3b5dbe07289513219651709" resolved "https://registry.yarnpkg.com/webpack-dev-middleware/-/webpack-dev-middleware-1.12.2.tgz#f8fc1120ce3b4fc5680ceecb43d777966b21105e"
dependencies: dependencies:
memory-fs "~0.4.1" memory-fs "~0.4.1"
mime "^1.3.4" mime "^1.5.0"
path-is-absolute "^1.0.0" path-is-absolute "^1.0.0"
range-parser "^1.0.3" range-parser "^1.0.3"
time-stamp "^2.0.0" time-stamp "^2.0.0"
webpack-dev-server@^2.4.4: webpack-dev-server@^2.4.4:
version "2.9.4" version "2.9.5"
resolved "https://registry.yarnpkg.com/webpack-dev-server/-/webpack-dev-server-2.9.4.tgz#7883e61759c6a4b33e9b19ec4037bd4ab61428d1" resolved "https://registry.yarnpkg.com/webpack-dev-server/-/webpack-dev-server-2.9.5.tgz#79336fba0087a66ae491f4869f6545775b18daa8"
dependencies: dependencies:
ansi-html "0.0.7" ansi-html "0.0.7"
array-includes "^3.0.3" array-includes "^3.0.3"
@ -6474,7 +6675,7 @@ webpack-dev-server@^2.4.4:
connect-history-api-fallback "^1.3.0" connect-history-api-fallback "^1.3.0"
debug "^3.1.0" debug "^3.1.0"
del "^3.0.0" del "^3.0.0"
express "^4.13.3" express "^4.16.2"
html-entities "^1.2.0" html-entities "^1.2.0"
http-proxy-middleware "~0.17.4" http-proxy-middleware "~0.17.4"
import-local "^0.1.1" import-local "^0.1.1"
@ -6509,8 +6710,8 @@ webpack-notifier@^1.5.0:
strip-ansi "^3.0.1" strip-ansi "^3.0.1"
webpack-sources@^1.0.1: webpack-sources@^1.0.1:
version "1.0.2" version "1.1.0"
resolved "https://registry.yarnpkg.com/webpack-sources/-/webpack-sources-1.0.2.tgz#d0148ec083b3b5ccef1035a6b3ec16442983b27a" resolved "https://registry.yarnpkg.com/webpack-sources/-/webpack-sources-1.1.0.tgz#a101ebae59d6507354d71d8013950a3a8b7a5a54"
dependencies: dependencies:
source-list-map "^2.0.0" source-list-map "^2.0.0"
source-map "~0.6.1" source-map "~0.6.1"
@ -6542,8 +6743,8 @@ webpack@^1.12.0:
webpack-core "~0.6.9" webpack-core "~0.6.9"
webpack@^3.0.0: webpack@^3.0.0:
version "3.8.1" version "3.9.1"
resolved "https://registry.yarnpkg.com/webpack/-/webpack-3.8.1.tgz#b16968a81100abe61608b0153c9159ef8bb2bd83" resolved "https://registry.yarnpkg.com/webpack/-/webpack-3.9.1.tgz#9a60aa544ed5d4d454c069e3f521aa007e02643c"
dependencies: dependencies:
acorn "^5.0.0" acorn "^5.0.0"
acorn-dynamic-import "^2.0.0" acorn-dynamic-import "^2.0.0"
@ -6648,6 +6849,15 @@ write@^0.2.1:
dependencies: dependencies:
mkdirp "^0.5.1" mkdirp "^0.5.1"
xhr@^2.0.1:
version "2.4.0"
resolved "https://registry.yarnpkg.com/xhr/-/xhr-2.4.0.tgz#e16e66a45f869861eeefab416d5eff722dc40993"
dependencies:
global "~4.3.0"
is-function "^1.0.1"
parse-headers "^2.0.0"
xtend "^4.0.0"
xss-filters@^1.2.6: xss-filters@^1.2.6:
version "1.2.7" version "1.2.7"
resolved "https://registry.yarnpkg.com/xss-filters/-/xss-filters-1.2.7.tgz#59fa1de201f36f2f3470dcac5f58ccc2830b0a9a" resolved "https://registry.yarnpkg.com/xss-filters/-/xss-filters-1.2.7.tgz#59fa1de201f36f2f3470dcac5f58ccc2830b0a9a"