-
-
Notifications
You must be signed in to change notification settings - Fork 554
react: Fold expect_callback_values into set_value #1196
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
Conversation
The necessary diff to the verify script to verify this should remain the most recent commit of https://github.com/petertseng/exercism-problem-specifications/commits/verify-react . As of the current moment, that would be petertseng@6a8b82d, but obviously I can't correct that stays correct forever, since I may need to rebase. |
aside: This makes it abundantly clear that there is something that has never been tested: Ensuring that a |
If #1197 is merged before #1196, the version number progression will be 1.2.0 -> 1.3.0 -> 2.0.0. It does not matter to me which path is taken. In the absence of other feedback, I will arrange so that the final version is 2.0.0, but if there is a large disparity in time of Approval (in the GitHub sense) of the two PRs, I will of course take the appropriate path dictated by those Approvals. |
@petertseng Great improvement. Is this ready to be merged? |
react 2.0.0 expect_callback_values is often not precise enough about which `set_value` calls should result in which callbacks being called or not called. "callbacks can be added and removed" is the worst offender, expecting a `[32, 42]` from callback2 only after both `set_value` have fired. That means for all we know, maybe an implementation: * magically manages to predict the future and calls the callback twice on the first `set_value`, with the correct value, and then zero times on the second `set_value`. * calls the callback zero times on the first `set_value`, but twice on the second `set_value`. To remedy this, we observe that the only time callbacks might be called is if there was a `set_value`. So, let's explicitly associate our callback expectations along with each `set_value`.
The last reviewed commit (inspect the commit designated by "View changes") was 253ec11. On my rebase, the diff-of-diff is as follows:
--- /proc/self/fd/11 2018-04-13 07:19:14.784913940 +0000
+++ /proc/self/fd/12 2018-04-13 07:19:14.786913896 +0000
@@ -1,11 +1,11 @@
diff --git a/exercises/react/canonical-data.json b/exercises/react/canonical-data.json
-index 8774bacd..3312fc3b 100644
+index 2803aaa0..57240595 100644
--- a/exercises/react/canonical-data.json
+++ b/exercises/react/canonical-data.json
@@ -1,6 +1,6 @@
{
"exercise": "react",
-- "version": "1.2.0",
+- "version": "1.3.0",
+ "version": "2.0.0",
"comments": [
"Note that, due to the nature of this exercise,",
@@ -102,7 +102,30 @@
}
]
},
-@@ -392,7 +381,11 @@
+@@ -398,17 +387,11 @@
+ {
+ "type": "set_value",
+ "cell": "input",
+- "value": 10
+- },
+- {
+- "type": "expect_callback_values",
+- "callback": "callback1",
+- "values": [11]
+- },
+- {
+- "type": "expect_callback_values",
+- "callback": "callback2",
+- "values": [9]
++ "value": 10,
++ "expect_callbacks": {
++ "callback1": 11,
++ "callback2": 9
++ }
+ }
+ ]
+ },
+@@ -445,7 +428,11 @@
{
"type": "set_value",
"cell": "input",
@@ -115,7 +138,7 @@
},
{
"type": "remove_callback",
-@@ -407,22 +400,12 @@
+@@ -460,22 +447,12 @@
{
"type": "set_value",
"cell": "input",
@@ -144,7 +167,7 @@
}
]
},
-@@ -479,17 +462,11 @@
+@@ -532,17 +509,11 @@
{
"type": "set_value",
"cell": "input",
@@ -167,7 +190,7 @@
}
]
},
-@@ -543,12 +520,10 @@
+@@ -596,12 +567,10 @@
{
"type": "set_value",
"cell": "input",
@@ -184,7 +207,7 @@
}
]
},
-@@ -597,27 +572,26 @@
+@@ -650,27 +619,26 @@
{
"type": "set_value",
"cell": "input", As you can see, Further, I can document that petertseng@1f62396 successfully verifies this file; the necessary documentation is the Travis CI build https://travis-ci.org/petertseng/exercism-problem-specifications/builds/365978540. Therefore, I treat the last Approval as authoritative, and therefore that I can merge this.
Yes. Thank you for reviewing! |
2.0.0: Combine expectCallbacks into exercism/problem-specifications#1196 was already performed pre-emptively in exercism#63 1.3.0: Multiple cells (the actual change here): exercism/problem-specifications#1197
2.0.0: Combine expectCallbacks into setvalue: exercism/problem-specifications#1196 was already performed pre-emptively in #63 1.3.0: Multiple cells (the actual change here): exercism/problem-specifications#1197
For those wondering if any test suites will actually need to change: Mostly not; the two ways of expressing callback expectations are isomorphic. However, my hope is that this way makes the intent clearer to implementors of this exercise. However, I did sneak in one functional change, and that is to "callbacks can be added and removed", as the PR description states. For those looking to go from 1.3.0 to 2.0.0, look at what changes in that function (explicit expectations after each It was not the wisest to combine the two operations (The transformation which changes no functionality, and one functionality change) into one commit, so I apologise for that. |
react 2.0.0
expect_callback_values is often not precise enough about which
set_value
calls should result in which callbacks being called or notcalled. "callbacks can be added and removed" is the worst offender,
expecting a
[32, 42]
from callback2 only after bothset_value
havefired.
That means for all we know, maybe an implementation:
on the first
set_value
, with the correct value, and then zero timeson the second
set_value
.set_value
, but twiceon the second
set_value
.To remedy this, we observe that the only time callbacks might be called
is if there was a
set_value
. So, let's explicitly associate ourcallback expectations along with each
set_value
.