Closed DanielRosenwasser closed 2 years ago
To add some thoughts to the tagged template examples:
- Use cases here aren't super compelling, but feels like they could be?
- Let's see more
Just the use case of
/** @type {HTMLDivElement} */
const div = html`<div>
<${SomeComponent} fooProp=${123 /*fooProp accepts numbers only*/} />
<${SomeComponent} fooProp=${"bar" /*type error*/} />
</div>`
is compelling enough. This means people can write type-safe DOM applications (or other applications in places similar to React native that render a declarative tree to native UI components), including type safety within the template string markup, without requiring a build step to transform JSX. For example, that code snippet could be pasted from VS Code (where the user would be able to catch errors in the html template) to CodePen and it would just work.
This is a moderate 👎 - we think we'd be encouraging people to use the wrong tools to solve these problems
I don't think that using a build-less setup is the wrong tool in every case. There are very valid reasons to use no build tools:
Furthermore, build steps can optionally compile template tag strings to optimized formats just like with JSX, with the benefit that code can be written one way and it would work in both build-less or build-full setups; optimization when needed. That, with added type safety, is a nice win.
"I want to write a full GraphQL parser and provide exact API shapes back"
This is a moderate 👎 - we think we'd be encouraging people to use the wrong tools to solve these problems
Why are type-safe tagged template strings the wrong tool for declaring Graphql queries and what would be a better solution? The graphql codgen https://www.graphql-code-generator.com/plugins/gql-tag-operations-preset provides something similar but has to use the somewhat awkward convention gql(/* GraphQL */ query)
due to the limitations of TS support for tagged templates.
- "I want to write a full HTML parser and provide the same checking that JSX gives"
- "I want to write a full GraphQL parser and provide exact API shapes back"
- This is a moderate 👎 - we think we'd be encouraging people to use the wrong tools to solve these problems
Well, a full parser would probably be infeasible anyway due to type instantiation and recursion limits, but a simplified parser that correctly infers the return type of the html`<div>${text}</div>`
expression as HTMLDivElement
would be useful.
Please revisit generic type for template literals.
Consistently Filtering Out Negative Matches when Narrowing
https://github.com/microsoft/TypeScript/pull/45205 https://github.com/microsoft/TypeScript/pull/41821
Playground Samples
obj1
andobj2
should not be related to whatever's being assigned.obj3
, but for various reasons we consider it to be "infinitely expanding" and just let that slip by the type system.https://github.com/microsoft/TypeScript/pull/41821 is similar in spirit, but feels less like a hack - ensure that if one side isn't changing, we don't prematurely consider the type to be infinitely expanding.
What do you do when you have two types that link back to themselves?
Tagged Template Inferrence and Making TemplateStringsArray
https://github.com/microsoft/TypeScript/issues/31422 https://github.com/microsoft/TypeScript/issues/33304 https://github.com/microsoft/TypeScript/pull/45310
Notes from @RyanCavanaugh
tsa
looks like aReadonlyArray<string>
, plus araw
propertyT extends string
x
isTemplateStringsArray
TParts
andTRawParts