Repository navigation
Design Meeting Notes, 8/18/2021 #45504
Description
Activity
To add some thoughts to the tagged template examples:
- Internationalization example = "I want parity between what regular functions provide and tagged template strings:"
* This is a weak 👍 - we like when the language is more consistent. - Favorite markup/query language examples =
- "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
Reacted by Paul Melero and Jesse PenceReacted by ExE Boss- Internationalization example = "I want parity between what regular functions provide and tagged template strings:"
- 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.
Reacted by ExE Boss, Jay Harris, Jesse Pence and Sebastian Nemeth- Use cases here aren't super compelling, but feels like they could be?
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:
- small apps where the cost of managing build setups is not worth it.
- one-off solutions where startup time does not matter (f.e. write a kiosk app for a one-time conference gathering, you have all morning to start the app, then it just needs to run)
- production applications where the performance cost of runtime template compilation doesn't matter.
- ease of use in getting started: teaching people to write apps while having type safety, getting them off the ground and running without complications, without cognitive overhead from learning build tools (and all the way in which they can fail).
- etc
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.
Reacted by ExE Boss, Peter Matta, Jesse Pence and Sebastian Nemeth-
"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.Reacted by ExE Boss, Oliver Bell, David J. Hamilton, Jay Harris, Jesse Pence and Sebastian NemethReacted by ExE Boss-
- "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 asHTMLDivElementwould be useful.Reacted by Jay Harris and Sebastian NemethPlease revisit generic type for template literals.
Reacted by Michael Herland Valen, David J. Hamilton, Paul Melero, Jay Harris, Jesse Pence and Sebastian NemethReacted by Michael Herland ValenReacted by Michael Herland ValenReacted by Michael Herland Valen and Paul MeleroReacted by Brian Kimwe think we'd be encouraging people to use the wrong tools to solve these problems
This is the weakest argument I've ever heard coming from the authors of a turing-complete meta language with a tail-optimized recursion depth of 1000 (which can apparently be bypassed too)
An important subset of SQL is clearly expressible within these limitations. I'm not talking about input safety, we have databases for that. I'm talking about typing
let res = await sql`SELECT ${Table['*']}, ${Other['url']} FROM ${Table} t LEFT JOIN ${Other} o ON t.noneya = o.beeswax`
... to
Table | Pick<Other, 'url'>Instead we get to work with ORMs defining their own javascript DSL that's somehow both leaky and incomplete, because those must be the right tool to solve these problems
Consistently Filtering Out Negative Matches when Narrowing
#45205
#41821
Playground Samples
obj1andobj2should 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.So this avoids tracking "runs" of the same recurring type.
What do you do when you have two types that link back to themselves?
Tagged Template Inferrence and Making TemplateStringsArray
#31422
#33304
#45310
Notes from Ryan Cavanaugh (@RyanCavanaugh)
tsalooks like aReadonlyArray<string>, plus arawpropertyT extends stringxisTemplateStringsArrayTPartsandTRawParts