Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

useReducer in calculator #1

Merged
merged 2 commits into from
Jan 3, 2019

Conversation

jchavarri
Copy link

Test using useReducer in calculator

@jchavarri
Copy link
Author

Commenting in revery-ui#174 (comment) 🙂

@OhadRau
Copy link
Owner

OhadRau commented Jan 3, 2019

This looks really good to me. I'll review this as soon as I'm done with lunch

Copy link
Owner

@OhadRau OhadRau left a comment

Choose a reason for hiding this comment

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

This looks great. I made two little comments but both are pretty minor things that I can look into before this gets merged. Thanks for taking the time to work on this!

}
| ClearKeyPressed(ac) =>
ac ?
{...state, operator: `Nop, result: 0., display: ""} :
Copy link
Owner

Choose a reason for hiding this comment

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

Shouldn't this also clear the number field? Otherwise, this'll only clear the current equation but leave the current value "typed in"

Copy link
Author

Choose a reason for hiding this comment

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

Oh right, great catch! I thought the existing statement was an if/else but the reset of curNum was always happening. Fixed in 240b993. 👍

};
setCurNum("");
};
let eval = (state, newOp) => {
Copy link
Owner

Choose a reason for hiding this comment

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

Now that we have the reducer, maybe we can refactor eval into an action? Thoughts on this?

Copy link
Author

Choose a reason for hiding this comment

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

I think eval wouldn't really fit an action-like role. My mental model for actions is "actions are like newspapers", in the sense that actions need to tell you something that happened in your app (generally user originated, or network originated). This talk has a really great overview on what are good candidates for actions: https://youtu.be/Dm9NgjR5Jn4?t=485

eval would fit more a "command" role. Because multiple actions (in this case 2) need to perform the evaluation, I think it makes sense to keep eval as just a helper function that encapsulates the common logic in the two actions reducers. There are plenty of ways to solve this though 😄 Do you think we should rethink the way eval and the current actions fit together?

Copy link
Author

Choose a reason for hiding this comment

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

One rule of thumb for actions is to try to use the past tense to model them. So things like KeyPressed or NetworkMessageReceived would be good candidates for actions, but ProcessQueue or CalculateDeviation would not be as good (they are more "command like" and probably need to live in the reducer as helper functions). I hope that makes sense!

@jchavarri
Copy link
Author

Thanks @OhadRau for the quick review! I fixed the issue with ClearKeyPressed handling, and added some thoughts about the eval treatment. Let me know what you think and feel free to merge and take over if you think this is g2g! 👍

@OhadRau
Copy link
Owner

OhadRau commented Jan 3, 2019

Great! Merging this now

@OhadRau OhadRau merged commit acb5653 into OhadRau:calculator Jan 3, 2019
@jchavarri jchavarri deleted the calculator-reducer branch January 4, 2019 01:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants