You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The type signature for __unsafeRenderFn, shown below, implies that render functions will take a set of props and numerous child Nodes as input, and will return a Node.
This is completely not the case. Based on the code, all calls to node[RenderFn] pass two arguments, the attributes of the node (which will be of type Record<string, string>) and the rendered children, as an object of type { value: string }. The function is expected to return not a Node, but either a plain string, which will be treated as a text node, or a string marked with __unsafeHTML, which will be rendered without being escaped. This discrepancy in types means that the types for the swap transformer, for example, are lackluster, with lots of any types even though the types are actually known.
I would be happy to contribute a fix for these types, but wanted to make sure that the behavior here is actually what is expected before doing so.
The text was updated successfully, but these errors were encountered:
The type signature for
__unsafeRenderFn
, shown below, implies that render functions will take a set of props and numerous childNode
s as input, and will return aNode
.This is completely not the case. Based on the code, all calls to
node[RenderFn]
pass two arguments, the attributes of the node (which will be of typeRecord<string, string>
) and the rendered children, as an object of type{ value: string }
. The function is expected to return not aNode
, but either a plain string, which will be treated as a text node, or a string marked with__unsafeHTML
, which will be rendered without being escaped. This discrepancy in types means that the types for theswap
transformer, for example, are lackluster, with lots ofany
types even though the types are actually known.I would be happy to contribute a fix for these types, but wanted to make sure that the behavior here is actually what is expected before doing so.
The text was updated successfully, but these errors were encountered: