react: Update tests to v2.0.0

[mrcfps]

Closes #1257. Canonical Data.

[cmccandless]

I noticed this example solution fails a new test I've suggested at exercism/problem-specifications#1194. Here is an implementation of the test for your convenience.

[cmccandless]

Should probably be test_callbacks_only_fire_on_change

[cmccandless]

I've been thinking about this: I'm not sure that this is the best interpretation of the canonical data, particularly regarding callbacks. As @petertseng pointed out, callbacks should just be executable code; they shouldn't "remember" anything.

I'll have to spend some time thinking about a better way to do this. If you can come up with something first, feel free to refactor and update this PR.

[mrcfps]

@cmccandless My apologies for this weird implementation of Callback. Actually callbacks in the real world are notoriously difficult to test and debug (Node.js developers should have the same feeling). I won't take action until canonical data makes this clear.

[mrcfps]

There are still two open PRs, namely exercism/problem-specifications#1196 and exercism/problem-specifications#1197, so I'm not sure what is the stable version of canonical data. Maybe in this PR updating to v1.2.0 is enough, and we can open another PR to handle later updates.

[cmccandless]

I'm still not sure about this implementation for callbacks... If at all possible, I think I would like to get back to callbacks being essentially just a function (or method).

[cmccandless]

I'm not sure that I like expect_callback_values being a member of ComputeCell...

What do you think about something like this?

callback_buffer = []
output.add_callback(callback_buffer.append)
input_.value = 3
self.assertEqual(callback_buffer, [4])

[mrcfps]

You mean convert callback to callback_buffer, and keep outputs of callbacks in the buffer? If so, I guess problem specification of this exercise should be changed, too.

My justification for expect_callback_values being a member of ComputeCell is that ComputeCell seems to be acting as a host for callbacks to be attached to and detached from. Or you can imagine callbacks as plugins for the ComputeCell, so trying to obtain output values of a callback is like reading the state of a plugin.

However, these are just analogies. Insights are welcome.

[cmccandless]

There are discussions on rewording the canonical-data, but I don't think that semantic changes are necessary to it.

Or you can imagine callbacks as plugins for the ComputeCell, so trying to obtain output values of a callback is like reading the state of a plugin.

Close: this is more of a publisher/subscriber scenario. The ComputerCell "publishes" new values by calling the registered callbacks. The callback is the subscription mechanism. The publisher doesn't care what the subscriber object is or how it uses the published data, and has no access to it. In a practical use case, if one were trying to use the solution for this exercise to perform calculations, they might simply use output.add_callback(lambda v: print(v))

I don't remember if I linked @petertseng's comment before (exercism/problem-specifications#1194 (comment)), but it's a good in-context note on what a callback is/should be.

[stale]

This issue has been automatically marked as abandoned because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mrcfps]

@cmccandless I've made up my mind to update this exercise to canonical v2.0.0 as soon as I can (sorry for the long delay). Here are two ways to implement unit tests related to callbacks (just take test_compute_cells_fire_callbacks for example):

• Your suggested way from above:

def test_compute_cells_fire_callbacks(self):
    input_ = InputCell(1)
    output = ComputeCell([input_], lambda inputs: inputs[0] + 1)
    callback_buffer = []

    output.add_callback(callback_buffer.append)
    input_.value = 3
    self.assertEqual(callback_buffer, [4])

But it seems that expect_callbacks operation in canonical data expects only one value for each callback, not an array or a list:

{
  "type": "set_value",
  "cell": "input",
  "value": 3,
  "expect_callbacks": {
    "callback1": 4
  }
}

• Mine (hack but more intuitive)

from functools import partial

def test_compute_cells_fire_callbacks(self):
    input_ = InputCell(1)
    output = ComputeCell([input_], lambda inputs: inputs[0] + 1)
    observer = float('inf')

    def callback1(observer, value):
        observer = value  # noqa

    output.add_callback(partial(callback1, observer))
    input_.value = 3
    self.assertEqual(observer, 4)

The reason I resort to partial magic here is that observer within test_compute_cells_fire_callbacks cannot be accessed in callback1 (thanks to Python's weird lexical scope), so we have to pass observer as a parameter. Maybe I'm detouring too much? Clever improvements are welcome.

[cmccandless]

I like the use of callback_factory and functools.partial! Good changes.

[cmccandless]

@mrcfps merged; thanks for all your work on this PR!