fix(core): clean up event-handling in ViewCommon #10534
Conversation
| // If it's a gesture (and this Observable declares e.g. `static tapEvent`) | ||
| if (gesture && !this._isEvent(normalizedName)) { |
There was a problem hiding this comment.
A very curious case is when it's a gesture (e.g. "tap") and yet the View hasn't declared static tapEvent. We'll fall through to the next case, which just treats it as a regular event named "tap" rather than setting up a tap gesture observer. This has long/always been the case, so I decided not to change it.
I don't have the appetite to change it during this PR that's just focused on cleanup, but any thoughts about this anyway? Why is it necessary in the first place to declare static tapEvent on a ViewBase in order for it to be treated as a gesture event? Is that still an appropriate idea, or would it make sense to remove those across all classes by removing this condition?
There was a problem hiding this comment.
Those static properties are for vanilla to be able to distinguish properties from events because XML format does not help in that matter.
We could get rid of those static properties across all classes possibly by doing a breaking change on vanilla and expect event declarations to have something like on prefix in XML.
<!-- 'on' helps distinguish events from properties -->
<Label text="Hello world" on:tap="dosomething"/>|
|
||
| // Coerce "tap" -> GestureTypes.tap | ||
| // Coerce "loaded" -> undefined | ||
| const gesture: GestureTypes | undefined = gestureFromString(normalizedName); |
There was a problem hiding this comment.
Desperate for TypeScript strict mode 😔
|
For a follow-up PR: would be worth checking that addObservers and removeObservers follow all the same rules as addEventListener and removeEventListener (i.e. checking whether thisArg matches). |
5b9d24f to
8ba69ad
Compare
ViewCommon splits event names redundantly (the superclass, Observable, splits event names too).
8ba69ad to
6311592
Compare
|
@farfromrefug I've dealt with that redundant code now. Removing support for multiple events altogether is something I'd prefer to do in a separate followup PR, as it would surely be slowed down by discussion of migration/deprecation path. |
Relates to #10531. These two PRs are independent and can be merged in either order.
Cleans up the code related to event-handling in ViewCommon.
It makes it a lot clearer that we're actually splitting event names both here and again in Observable! So in a follow-up PR after this and the related PR, we can investigate removing event name splitting altogether.
PR Checklist
What is the current behavior?
There's some unclear, redundant code.
What is the new behavior?
I've made the code clear and readable.