Check whether a focus state transition occurs

[zhang-peter]

Checking for valid state transitions is necessary because _handleFocusChanged is called when Spinbox are enabled or disabled.
I did not make this pull request when #80 occur because I am not sure what cause the problem.
Now I found that is relative to FocusNode behavior when propery canRequestFocus is changed in TextField. I believe this pull request can close #80.

[jpnurmi]

tracking "previous" state without dealing with didUpdateWidget() tends to result in things getting out of sync when the widget is rebuilt. what if we relied on FocusNode.canRequestFocus instead to avoid our own book keeping? it should be false if the widget is disabled and thus, not focusable, right?

if (_focusNode.canRequestFocus) widget.onSubmitted?.call(value);

[zhang-peter]

tracking "previous" state without dealing with didUpdateWidget() tends to result in things getting out of sync when the widget is rebuilt. what if we relied on FocusNode.canRequestFocus instead to avoid our own book keeping? it should be false if the widget is disabled and thus, not focusable, right?

if (_focusNode.canRequestFocus) widget.onSubmitted?.call(value);

I will check sync about didUpdateWidget. But FocusNode.canRequestFocus condition only avoid submit action when disable Spinbox. Enable Spinbox can still trigger submit action.

[jpnurmi]

Alternatively, we could propagate the "enabled" value from SpinBox and CupertinoSpinBox to BaseSpinBox or SpinBoxMixin so that it knows the value.

[zhang-peter]

"enabled" value from SpinBox and CupertinoSpinBox also can't avoid submit action when enable a disabled Spinbox, because "enabled" is always true in this situation.

[wszak]

I will check sync about didUpdateWidget. But FocusNode.canRequestFocus condition only avoid submit action when disable Spinbox. Enable Spinbox can still trigger submit action.

How about something like:

        final oldValue = _value;
        final newValue = fixupValue(_controller.text);
        if (newValue != oldValue && _focusNode.canRequestFocus) widget.onSubmitted?.call(newValue);

So onSubmitted is called only when the value changes, like in setValue.
Change in focus doesn't change value, so it should work for your case too.

[zhang-peter]

I will check sync about didUpdateWidget. But FocusNode.canRequestFocus condition only avoid submit action when disable Spinbox. Enable Spinbox can still trigger submit action.

How about something like:

        final oldValue = _value;
        final newValue = fixupValue(_controller.text);
        if (newValue != oldValue && _focusNode.canRequestFocus) widget.onSubmitted?.call(newValue);

So onSubmitted is called only when the value changes, like in setValue. Change in focus doesn't change value, so it should work for your case too.

Actually, your proposition can cover most case. But a submit aciton is usually tiggered when an input widget lose focus or Enter key is pressed in other UI library, like Qt.
I think we should obey this convention for convenience.

[zhang-peter]

Hi @jpnurmi , I don't think there will be a synchronization problem without dealing with didUpdateWidget() after viewing the code。
hasFocus is property of _focusNode which is final type. _focusNode is determined when state is initilized.
I also move initialization of _hasFocusPrev to initState in new commit. It seems more reasonable.