Skip to content
This repository was archived by the owner on Sep 2, 2023. It is now read-only.

Conversation

DanSallau
Copy link
Contributor

@DanSallau DanSallau commented Aug 2, 2016

The attached PR show simply warn user on the timeformat should the format be wrong . E.g 33:333:23 . Hrs shouldn't be greater than 24 presumably Hence the warning. This however is not a wrong time as 33 hrs can be translated to 2 days 9 hrs and the two days be added to the date field should the user choose to proceed.

Ticket : https://trello.com/c/kv3hj0KG/37-github-nuru-safari-firefox-no-validations-for-date-time-fields

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 28.589% when pulling d567c48 on nuruddeensalihu:nuru/warn_user_onTime into 4f8f6c1 on binary-com:master.

const { dateStart } = this.props;
const inputValue = returnValidTime(e.target.value, ':');
if (isValidTime(inputValue)) {
showError('Time format is wrong!');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not going to use showError to display errors any more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@borisyankov what are we going to use instead
?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ErrorMsg component

@DanSallau DanSallau closed this Aug 2, 2016
@DanSallau DanSallau reopened this Aug 2, 2016
@DanSallau DanSallau closed this Aug 2, 2016
@DanSallau DanSallau reopened this Aug 2, 2016
@coveralls
Copy link

Coverage Status

Coverage increased (+0.006%) to 28.606% when pulling ae885f9 on nuruddeensalihu:nuru/warn_user_onTime into 4f8f6c1 on binary-com:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.006%) to 28.606% when pulling ae885f9 on nuruddeensalihu:nuru/warn_user_onTime into 4f8f6c1 on binary-com:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.006%) to 28.606% when pulling ae885f9 on nuruddeensalihu:nuru/warn_user_onTime into 4f8f6c1 on binary-com:master.

onTimeChange = e => {
const { dateStart } = this.props;
const inputValue = returnValidTime(e.target.value, ':');
this.setState({ isInValidTime: isValidTime(inputValue) });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need this to be state, in can be calculated on render.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 31.61% when pulling e59e782 on nuruddeensalihu:nuru/warn_user_onTime into 92c77c1 on binary-com:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) to 31.61% when pulling e59e782 on nuruddeensalihu:nuru/warn_user_onTime into 92c77c1 on binary-com:master.


if (durationAllowed) {
if (isValidTime(time)) {
yield put(updateTradeError(index, 'durationError', 'Time format is wrong!'));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that yield is not return, if you want to exit early, explicit return is needed

@nuruddeensalihu

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think either of the two serve our purpose here, There isn't a code block after the if statement so the block exit there. Plus 'return' is part of what the yield keyword does it self if i understand correctly. I think either of the two should be fine(i.e return or not ). https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Operators/yield

Copy link
Contributor

@qingweibinary qingweibinary Aug 4, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's better to have

if (xxx) {
   ...
   return
}

if (yyyy) {
   ...
   return
}

than to have

if (xxx) {
   ...
} else if (yyyy) {
   ...
}
...
return

The first one is generally better, it tells reader that code exit with that condition, and that's all it does, 2nd chunk however requires reader to go until the end of code to know what's going on

I might have make the mistake at the first place, would you help me to fix it altogether?
Thanks

Copy link
Contributor Author

@DanSallau DanSallau Aug 4, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qingweibinary would have a look.

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.6%) to 30.012% when pulling adf60bf on nuruddeensalihu:nuru/warn_user_onTime into 92c77c1 on binary-com:master.

@borisyankov borisyankov merged commit 31c7a72 into regentmarkets-repo-archive:master Aug 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants