ShapeShift integration #652

Merged
neb-b merged 7 commits from shapeshift into master 2017-12-06 01:33:41 +01:00
5 changed files with 73 additions and 9 deletions
Showing only changes of commit d4b4b78e10 - Show all commits

View file

@ -5,6 +5,7 @@ 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
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"; import Address from "component/address";
import Link from "component/link"; import Link from "component/link";
import type { Dispatch } from "redux/actions/shape_shift"; import type { Dispatch } from "redux/actions/shape_shift";
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
type Props = { type Props = {
shiftState: ?string, shiftState: ?string,
@ -16,6 +17,10 @@ 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
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, clearShapeShift: Dispatch,
doShowSnackBar: Dispatch, doShowSnackBar: Dispatch,
getActiveShift: Dispatch, getActiveShift: Dispatch,
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
}; };
class ActiveShapeShift extends React.PureComponent<Props> { class ActiveShapeShift extends React.PureComponent<Props> {
@ -63,6 +68,9 @@ 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
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,
clearShapeShift, clearShapeShift,
doShowSnackBar, doShowSnackBar,
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; } = this.props;
return ( return (
@ -76,6 +84,13 @@ 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
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>{" "} </span>{" "}
to the address below. to the address below.
</p> </p>
<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
<div className="shapeshift__deposit-address-wrapper"> <div className="shapeshift__deposit-address-wrapper">
<Address address={shiftDepositAddress} showCopyButton /> <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
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

@ -3,6 +3,7 @@ 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
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"; import { getExampleAddress } from "util/shape_shift";
import { Submit, FormRow } from "component/form"; import { Submit, FormRow } from "component/form";
import type { ShapeShiftFormValues, Dispatch } from "redux/actions/shape_shift"; import type { ShapeShiftFormValues, Dispatch } from "redux/actions/shape_shift";
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
type ShapeShiftFormErrors = { type ShapeShiftFormErrors = {
returnAddress?: string, returnAddress?: string,
@ -24,6 +25,7 @@ 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
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, originCoinDepositFee: number,
originCoinDepositMin: string, originCoinDepositMin: string,
originCoinDepositMax: number, originCoinDepositMax: number,
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
}; };
export default (props: Props) => { export default (props: Props) => {
@ -43,6 +45,7 @@ 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
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,
originCoinDepositMin, originCoinDepositMin,
originCoinDepositFee, originCoinDepositFee,
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; } = props;
return ( return (
<form onSubmit={handleSubmit}> <form onSubmit={handleSubmit}>
@ -63,18 +66,18 @@ 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
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> </select>
<span> {__("for LBC")}</span> <span> {__("for LBC")}</span>
<p className="shapeshift__tx-info help"> <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
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 && {!updating &&
originCoinDepositMax && ( originCoinDepositMax && (
<span> <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
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
{__("Exchange max")}: {originCoinDepositMax} {originCoin} 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
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
<br /> 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
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
{__("Exchange minimun")}: {originCoinDepositMin} {originCoin} 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
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
<br /> 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
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
{__("Fee")}: {originCoinDepositFee} LBC 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
</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
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
)} )}
</p> </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
</div> </div>
<FormRow <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
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

@ -65,6 +65,7 @@ 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
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,
shiftOrderId, shiftOrderId,
shiftState, shiftState,
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; } = shapeShift;
const initialFormValues: ShapeShiftFormValues = { const initialFormValues: ShapeShiftFormValues = {
@ -116,6 +117,8 @@ 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
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} originCoinDepositMax={originCoinDepositMax}
originCoinDepositMin={originCoinDepositMin} originCoinDepositMin={originCoinDepositMin}
originCoinDepositFee={originCoinDepositFee} originCoinDepositFee={originCoinDepositFee}
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
/> />
)} )}
/> />
@ -131,6 +134,11 @@ 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
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} shiftState={shiftState}
clearShapeShift={clearShapeShift} clearShapeShift={clearShapeShift}
doShowSnackBar={doShowSnackBar} doShowSnackBar={doShowSnackBar}
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
/> />
)} )}
</div> </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

View file

@ -21,6 +21,7 @@ export type ShapeShiftState = {
// using Number(x) or parseInt(x) will either change it back to scientific notation or round to zero // using Number(x) or parseInt(x) will either change it back to scientific notation or round to zero
originCoinDepositMin: ?string, originCoinDepositMin: ?string,
originCoinDepositFee: ?number, originCoinDepositFee: ?number,
shapeShiftRate: ?number,
}; };
// All ShapeShift actions that will have some payload // All ShapeShift actions that will have some payload
@ -63,6 +64,7 @@ type ShapeShiftMarketInfo = {
limit: number, limit: number,
minimum: number, minimum: number,
minerFee: number, minerFee: number,
rate: number,
}; };
type ActiveShiftInfo = { type ActiveShiftInfo = {
@ -91,6 +93,7 @@ const defaultState: ShapeShiftState = {
originCoinDepositMax: undefined, originCoinDepositMax: undefined,
originCoinDepositMin: undefined, originCoinDepositMin: undefined,
originCoinDepositFee: undefined, originCoinDepositFee: undefined,
shapeShiftRate: undefined,
}; };
export default handleActions( export default handleActions(
@ -149,6 +152,7 @@ export default handleActions(
.toFixed(10) .toFixed(10)
.replace(/\.?0+$/, ""), .replace(/\.?0+$/, ""),
originCoinDepositFee: marketInfo.minerFee, originCoinDepositFee: marketInfo.minerFee,
shapeShiftRate: marketInfo.rate,
}; };
}, },
[actions.GET_COIN_STATS_FAIL]: ( [actions.GET_COIN_STATS_FAIL]: (