feat: add onTappedSquare to Chessboard widget, add squareHighlights field

[tom-anders]

We'll need this if we want to switch the coordinate trainer in the app
from ChessboardEditor to Chessboard in order to fix lichess-org/mobile#1017

[veloce]

I think we want to put that after the test if current pointer down event is null. Because we want to ensure the tap up event is coming from the same pointer as the down event pointer.

And it made me think of something else. I think we're missing another check: we don't want to trigger the callback if the square found on tap up is not the same as the one found on tap down. IE: the user taps a square and drags the finger to another square before releasing, in that case the onTappedSquare should not be called.

[veloce]

I realise this makes the logic more complex, but can we avoid it?

[tom-anders]

I think we want to put that after the test if current pointer down event is null. Because we want to ensure the tap up event is coming from the same pointer as the down event pointer.

This doesn't work, because if the board is non-interactive and shape drawing is disabled, the pointerDown listener is disabled entirely, so current pointer down event will always be nullptr. Or should we just enable the pointerDown handler always as well?

[veloce]

We probably want to enable all the Listener events all the time, otherwise it will be messy.

the pointerDown handler already exit if the board is not interactive. So for the tapped square callback you want to put the logic before that line. Adding a new variable and register the square on tap down to compare it with the square on tap up should be enough.

Normally the board logic is well tested, and this change should not break the existing tests hopefully.

This PR will need new tests to ensure the logic I mentioned above is working properly.

[tom-anders]

Done 👍

All tests still pass, and these lines verify that no we don't call onTappedSquare if pointer down and up are different squares (which is the case when dragging a piece)

Anything else that should be tested?

[tom-anders]

I can add a test of course that tests the logic directly, just want to check to avoid redundant work

[veloce]

I think a dedicated test would be good indeed. It adds another layer of documentation to understand the code and also we should test this in the case the board is not interactive (as opposed to during a piece drag where this callback is not really useful btw).

[tom-anders]

Added a test 👍

[veloce]

@tom-anders while testing this I realised we could not use a tap event with the coordinate trainer to recognise squares.

The reason is this feature is a race against the clock and people want to beat their score. A tap is slower than a bare touch, so we'd receive a lot of complaint that it is slow ;) Also on website it works with touch too.

So I pushed a commit with a suggested change.

[tom-anders]

@tom-anders while testing this I realised we could not use a tap event with the coordinate trainer to recognise squares.

The reason is this feature is a race against the clock and people want to beat their score. A tap is slower than a bare touch, so we'd receive a lot of complaint that it is slow ;) Also on website it works with touch too.

So I pushed a commit with a suggested change.

Ah yes that makes sense, thanks 👍