Typing renderable values #2359
-
I migrated an application to Lit 2.0 from the previous version when Lit 2.0 was released. One of the areas where we encountered some friction is related to changes in the return type for In the previous version of Lit, our It took me a while to make sense of some of the types that were showing up in warnings during the migration, such as:
I had to dive into the Lit source to fully appreciate what the now-parameterized In the source and API documentation I see that the return type of Instead, I tried creating types that represent renderable values, but it gets quite hairy:
There are very likely reasonable permutations that these unions overlook. I opted for just going with I was wondering if there are any recommendations for typing the return value of |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The reason that If in your codebase you'd like to exclude certain types from the universe of values lit will render, the approach of defining type aliases to that subset seems perfectly reasonable. |
Beta Was this translation helpful? Give feedback.
The reason that
render()
is typed asunknown
is that lit will happily render any value. For example, it's perfectly valid to pass{toString() { return 'hi!'; }
as a value to an expression, and lit will end up rendering thetoString()
value of it. So there is not a specific narrowing of types that Lit requires be passed to an expression.If in your codebase you'd like to exclude certain types from the universe of values lit will render, the approach of defining type aliases to that subset seems perfectly reasonable.