Commits on Oct 13, 2024

1. **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.

   

   trusktr committed Oct 13, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 37b7269
   • Browse repository at this point

   Copy the full SHA

   37b7269 View commit details

   Browse the repository at this point in the history