-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Labels
[STAGE-2] incomplete implementationRemove this label when implementation is completeRemove this label when implementation is complete[STAGE-2] not fully covered by tests yetRemove this label when tests are verified to cover the implementationRemove this label when tests are verified to cover the implementation[STAGE-2] unresolved discussions leftRemove this label when all critical discussions are resolved on the issueRemove this label when all critical discussions are resolved on the issue[STAGE-3] docs changes not added yetRemove this label when the necessary documentation for the feature / change is addedRemove this label when the necessary documentation for the feature / change is added[STAGE-3] missing 2 reviews for RFC PRsRemove this label when at least 2 core team members reviewed and approved the RFC implementationRemove this label when at least 2 core team members reviewed and approved the RFC implementation
Description
TL;DR: onCustom-Event$ in v1 encodes for the events customEvent and custom-event and with this RFC it would only encode for custom-event. Instead, you would need to write on_customEvent_$.
Plus bugfixes and performance improvements.
Champion
What's the motivation for this proposal?
Problems you are trying to solve:
- HTML attributes are case-insensitive and cannot have duplicates
- HTML event types are case sensitive
- all DOM events except
DOMContentLoadedare lowercase onQInit$andonQinit$are therefore the same thing,on:qinituseVisisibleTask$also adds a handler- this requires merging handlers. Right now this happens when creating VNodes
- custom events have can have any case (and many letters that are not allowed in attributes)
- We have
-encoding for event names: a-will capitalize the next letter.on-custom-event$is the same ason-Custom-Event$and creates the HTML attributeon:-custom-eventwhich is called when dispatching"CustomEvent".- this is not documented as far as I can find
- also,
onCustom-Eventwill fire for bothcustomEventandcustom-event
- This means that if the custom event is
custom-eventand the dev writesonCustom-Event$, it will not work, they have to writeonCustom--Event$ - This is error-prone and the handler merging is buggy
Proposed Solution / Feature
What do you propose?
(JSX-handler: onSomeEvent$; HTML-handler: on:someevent (no $))
- Do the conversion in JSXNode or _jsxSplit so that the JSXNode props never contain
onFoo$but instead immediatelyon:foo - Make the optimizer do this for string tags
<div onClick$={...}/>=>_jsxSorted('div', null, {"on:click": qrl(...)})
- Encode
-from JSX handlers<div onClick-Me$={...}/>=>_jsxSorted('div', null, {"on:click--me": qrl(...)})
- Add encoding for custom events:
on_CustomEvent_$. Starts with_and must end with_(or error), and anything inside is the event name<div on_clICk-Me_Now_$={...}/>=>_jsxSorted('div', null, {"on:cl-i-c-k---me_-Now": qrl(...)})
PRs/ Links / References
Metadata
Metadata
Assignees
Labels
[STAGE-2] incomplete implementationRemove this label when implementation is completeRemove this label when implementation is complete[STAGE-2] not fully covered by tests yetRemove this label when tests are verified to cover the implementationRemove this label when tests are verified to cover the implementation[STAGE-2] unresolved discussions leftRemove this label when all critical discussions are resolved on the issueRemove this label when all critical discussions are resolved on the issue[STAGE-3] docs changes not added yetRemove this label when the necessary documentation for the feature / change is addedRemove this label when the necessary documentation for the feature / change is added[STAGE-3] missing 2 reviews for RFC PRsRemove this label when at least 2 core team members reviewed and approved the RFC implementationRemove this label when at least 2 core team members reviewed and approved the RFC implementation
Type
Projects
Status
In Progress (STAGE 2)