Preact: Remove irrelevant types from JSX namespace

Created on 19 Aug 2020  路  5Comments  路  Source: preactjs/preact

The JSX namespace in TypeScript has a special meaning. There鈥檚 a specific set of types that can be defined in a JSX namespace to make JSX behave in a certain way. This is (partially) documented here.

The following properties have a special meaning:

  • Element
  • ElementClass
  • ElementAttributesProperty
  • ElementChildrenAttribute
  • IntrinsicAttributes
  • IntrinsicElements
  • LibraryManagedAttributes

However, in the Preact typings the following types are also defined on the JSX namespace:

  • SVGAttributes
  • PathAttributes
  • DOMAttributes
  • HTMLAttributes

Events and event handlers

  • TargetedEvent
  • TargetedAnimationEvent
  • TargetedClipboardEvent
  • TargetedCompositionEvent
  • TargetedDragEvent
  • TargetedFocusEvent
  • TargetedKeyboardEvent
  • TargetedMouseEvent
  • TargetedPointerEvent
  • TargetedTouchEvent
  • TargetedTransitionEvent
  • TargetedUIEvent
  • TargetedWheelEvent
  • EventHandler
  • AnimationEventHandler
  • ClipboardEventHandler
  • CompositionEventHandler
  • DragEventHandler
  • FocusEventHandler
  • GenericEventHandler
  • KeyboardEventHandler
  • MouseEventHandler
  • PointerEventHandler
  • TouchEventHandler
  • TransitionEventHandler
  • UIEventHandler
  • WheelEventHandler

The JSX namespace in Preact is called JSXInternal. This makes it unclear if these types are supposed to be consumed or not.

Since these types are useful, especially the event handlers, I propose to move all these types to the preact namespace instead. The JSXInternal namespace can import these types an expose type aliases using the @deprecated annotation. They can be removed in the next major release.

help wanted

Most helpful comment

FYI: We consciously moved away from the global JSX type so that we can co-exist with other JSX typings being present. This should remain. See the last section of the TypeScript docs on this page for more information: https://www.typescriptlang.org/docs/handbook/jsx.html#factory-functions

All 5 comments

That's awesome, sounds like you spent already a bit of time going through everything. Would love to have a PR for this :+1:

Makes sense to me. Seems this matches what the React types are doing as well so we are in good company to move these out.

FYI: We consciously moved away from the global JSX type so that we can co-exist with other JSX typings being present. This should remain. See the last section of the TypeScript docs on this page for more information: https://www.typescriptlang.org/docs/handbook/jsx.html#factory-functions

I learnt some things about TypeScript and JSX while writing mini-jsx.

I noticed in props.js a similar way is used to assign props to DOM nodes. This means the existing builtin TypeScript types from HTMLElementTagNameMap and SVGElementTagNameMap could be used to avoid the need to maintain most of the current HTMLAttributes interface in Preact.

This will also improve typings, i.e. an input has a checked property in the TypeScript DOM types, but not a div element. In Preact there鈥檚 currently no distinction.

Instead of introducing the deprecation policy I described in the original comment, I鈥檇 prefer to take the liberty to make some breaking changes.

Is there an ETA for Preact 11? I think it鈥檚 better to make these changes for a major release.

There is no ETA for Preact 11 and it's probably few months away. Personally I'm fine with doing this change in a 10.x release. Adding invalid props to DOM nodes should be a TypeError and even if the new typings will lead to new errors for existing code bases, that's ok for me. It's an error regardless and I'd spin it that our types simply missed that case.

The thing with TS types is that any change is a breaking one unless only new properties are added :shrug:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

philipwalton picture philipwalton  路  3Comments

kossnocorp picture kossnocorp  路  3Comments

KnisterPeter picture KnisterPeter  路  3Comments

youngwind picture youngwind  路  3Comments

k15a picture k15a  路  3Comments