ShapeShift integration #652
|
@ -5,6 +5,7 @@ import * as statuses from "constants/shape_shift";
|
|||
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
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 Link from "component/link";
|
||||
import type { Dispatch } from "redux/actions/shape_shift";
|
||||
import ShiftMarketInfo from "./market_info";
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
|
||||
type Props = {
|
||||
shiftState: ?string,
|
||||
|
@ -16,6 +17,10 @@ type Props = {
|
|||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
clearShapeShift: Dispatch,
|
||||
doShowSnackBar: Dispatch,
|
||||
getActiveShift: Dispatch,
|
||||
shapeShiftRate: ?number,
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoinDepositMax: ?number,
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoinDepositFee: ?number,
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoinDepositMin: ?string,
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
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> {
|
||||
|
@ -63,6 +68,9 @@ class ActiveShapeShift extends React.PureComponent<Props> {
|
|||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoinDepositMax,
|
||||
clearShapeShift,
|
||||
doShowSnackBar,
|
||||
shapeShiftRate,
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoinDepositFee,
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoinDepositMin,
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
} = this.props;
|
||||
|
||||
return (
|
||||
|
@ -76,6 +84,13 @@ class ActiveShapeShift extends React.PureComponent<Props> {
|
|||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
</span>{" "}
|
||||
to the address below.
|
||||
</p>
|
||||
<ShiftMarketInfo
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoin={shiftCoinType}
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
shapeShiftRate={shapeShiftRate}
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoinDepositFee={originCoinDepositFee}
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoinDepositMin={originCoinDepositMin}
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
originCoinDepositMax={originCoinDepositMax}
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
||||
/>
|
||||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
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">
|
||||
<Address address={shiftDepositAddress} showCopyButton />
|
||||
|
|
|||
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
Good idea Good idea
Try Try `button="text"` here.
Add "." Add "."
Add ".". Also, let's link to FAQ here again. Add ".". Also, let's link to FAQ here again.
I'm not in love with "New" here - maybe just "Reset"? Though I don't like this either. As a (potentially weird) user, I have a desire for things to be back in their default state when "Done". But I don'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.
Also this should probably be primary, whatever the label is. Also this should probably be primary, whatever the label is.
I'm not sure how much I like that button. What if they click it before actually sending? We would need some new bit of UI to say "We will keep pinging shapeshit to see if you actually sent it" (obviously worded better). We say "this will update automatically" and have a link to the shapeshift 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"
outside of the constructor, I think you need to add
outside of the constructor, I think you need to add
`continuousFetch: ?number;`
as per https://flow.org/en/docs/types/classes/
this should get rid of all the flow fix mes this should get rid of all the flow fix mes
|
|
@ -3,6 +3,7 @@ import Link from "component/link";
|
|||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
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 { Submit, FormRow } from "component/form";
|
||||
import type { ShapeShiftFormValues, Dispatch } from "redux/actions/shape_shift";
|
||||
import ShiftMarketInfo from "./market_info";
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
|
||||
type ShapeShiftFormErrors = {
|
||||
returnAddress?: string,
|
||||
|
@ -24,6 +25,7 @@ type Props = {
|
|||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
originCoinDepositFee: number,
|
||||
originCoinDepositMin: string,
|
||||
originCoinDepositMax: number,
|
||||
shapeShiftRate: number,
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
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) => {
|
||||
|
@ -43,6 +45,7 @@ export default (props: Props) => {
|
|||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
originCoinDepositMax,
|
||||
originCoinDepositMin,
|
||||
originCoinDepositFee,
|
||||
shapeShiftRate,
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
} = props;
|
||||
return (
|
||||
<form onSubmit={handleSubmit}>
|
||||
|
@ -63,18 +66,18 @@ export default (props: Props) => {
|
|||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
))}
|
||||
</select>
|
||||
<span> {__("for LBC")}</span>
|
||||
<p className="shapeshift__tx-info help">
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
<div className="shapeshift__tx-info">
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
{!updating &&
|
||||
originCoinDepositMax && (
|
||||
<span>
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
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}
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
<br />
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
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}
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
<br />
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
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
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
</span>
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
<ShiftMarketInfo
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
originCoin={originCoin}
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
shapeShiftRate={shapeShiftRate}
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
originCoinDepositFee={originCoinDepositFee}
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
originCoinDepositMin={originCoinDepositMin}
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
originCoinDepositMax={originCoinDepositMax}
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
/>
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
)}
|
||||
</p>
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
</div>
|
||||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
||||
</div>
|
||||
|
||||
<FormRow
|
||||
|
|
|||
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic Yeah definitely not a fan of the current input styling. I was thinking this was fine for now since the PR is getting bigger and bigger. But might as well do it now and avoid more tech debt. I will update the generic `input` style to be more inline with the wunderbar
I think this should stay as just classes with regular html elements. I can make my case more tomorrow, but my main idea is this: Shared components are good for elements that can very a lot, but only with small differences. Buttons have many different possible styles (different background colors, borders, labels, etc). A lot of different variation, but the component is generally the same, a box with some text in the middle. For this element ( If we start building out the shared components so much that they meet every possible use case, they can 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
Yes we can display the actual rate. I'll add that Yes we can display the actual rate. I'll add that
|
|
@ -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>
|
||||
);
|
||||
};
|
|
@ -65,6 +65,7 @@ class ShapeShift extends React.PureComponent<Props> {
|
|||
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
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,
|
||||
shiftOrderId,
|
||||
shiftState,
|
||||
shapeShiftRate,
|
||||
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;
|
||||
|
||||
const initialFormValues: ShapeShiftFormValues = {
|
||||
|
@ -116,6 +117,8 @@ class ShapeShift extends React.PureComponent<Props> {
|
|||
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
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}
|
||||
originCoinDepositMin={originCoinDepositMin}
|
||||
originCoinDepositFee={originCoinDepositFee}
|
||||
shapeShiftRate={shapeShiftRate}
|
||||
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}
|
||||
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> {
|
|||
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
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}
|
||||
clearShapeShift={clearShapeShift}
|
||||
doShowSnackBar={doShowSnackBar}
|
||||
originCoinDepositMax={originCoinDepositMax}
|
||||
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}
|
||||
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}
|
||||
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}
|
||||
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}
|
||||
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>
|
||||
|
|
|||
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
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
|
|
@ -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
|
||||
originCoinDepositMin: ?string,
|
||||
originCoinDepositFee: ?number,
|
||||
shapeShiftRate: ?number,
|
||||
};
|
||||
|
||||
// All ShapeShift actions that will have some payload
|
||||
|
@ -63,6 +64,7 @@ type ShapeShiftMarketInfo = {
|
|||
limit: number,
|
||||
minimum: number,
|
||||
minerFee: number,
|
||||
rate: number,
|
||||
};
|
||||
|
||||
type ActiveShiftInfo = {
|
||||
|
@ -91,6 +93,7 @@ const defaultState: ShapeShiftState = {
|
|||
originCoinDepositMax: undefined,
|
||||
originCoinDepositMin: undefined,
|
||||
originCoinDepositFee: undefined,
|
||||
shapeShiftRate: undefined,
|
||||
};
|
||||
|
||||
export default handleActions(
|
||||
|
@ -149,6 +152,7 @@ export default handleActions(
|
|||
.toFixed(10)
|
||||
.replace(/\.?0+$/, ""),
|
||||
originCoinDepositFee: marketInfo.minerFee,
|
||||
shapeShiftRate: marketInfo.rate,
|
||||
};
|
||||
},
|
||||
[actions.GET_COIN_STATS_FAIL]: (
|
||||
|
|
Good idea