-
Notifications
You must be signed in to change notification settings - Fork 6
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
**feat:** improve the JSX type helpers:
- `on*` event properties can now be specified to define event props for JSX. The README has an example, plus the `jsx-types-*.test.tsx` files show all the type test cases. - They will be mapped without string values, accepting only functions. - For Solid specifically, all the `on*` properties are also mapped to `on:*` JSX props with the same types. - Any boolean JSX props will also accept "true" and "false" string values. - Any number JSX props will also accept number strings, f.e. "1.23". - For Solid specifically, automatically map prop types for `attr:`, `prop:`, and `bool:` prefixed JSX props. - `attr:` props will accept only strings. - `attr:` props mapped from boolean JS properties will specifically accept "true" and "false" strings. - `attr:` props mapped from number JS properties will specifically accept number strings, f.e. "1.23". - Only boolean JS properties will map to `bool:` JSX props, and f.e. `bool:` will not be available for any number props. - `bool:` props will accept only booleans, and not the "true" or "false" strings (otherwise Solid will set the attribute to always exist regardless of the value, and this is not an issue with React props because React props always map to JS properties never attributes when it comes to Lume Elements). - The `attr:` props will accept only "true" or "false" strings. - The non-prefixed JSX props, and `prop:` props, will accept both booleans and "true" or "false" strings. - Number JS properties are mapped to JSX props that accept numbers as well as number strings, but similar to boolean properties: - The `attr:` props accept only number strings. - And there are no `bool:` props mapped for number properties. - **POSSIBLY BREAKING:**: This update adds JSX types for event properties, which has a tiny chance of being breaking. If you had a typed JSX prop like `onnotevent` for an element whose JSX types you defined with `ElementAttributes`, there might be a type error, but this scenario is unlikely. To migrate, use the `prop:` prefix to set the JS property instead, for example `prop:onnotevent={someValue}`. The additional prefixed props could also cause an `@ts-expect-error` somewhere to start erroring, or a type conflict, in which case some care is needed. **feat:** add a new `dispatchEventWithCall(event)` method This is similar to `dispatchEvent()`, but useful for dispatching a non-builtin event and causing any `on*` method for that event to also be called if it exists. With builtin events, for example, when the builtin `click` event is dispatched, the element's `.onclick()` method is called automatically if it exists. Now we can achieve the same behavior with custom events, so that for example `dispatchEventWithCall(new Event('myevent'))` will also cause `.onmyevent()` to be called if it exists. Note, avoid calling this method with an event that is not a custom event, or you'll trigger the respective builtin `on*` method twice.
- Loading branch information
Showing
19 changed files
with
905 additions
and
134 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.