Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: allow to use fallback value for BindingElement #12

Open
jwoo0122 opened this issue Aug 18, 2022 · 0 comments
Open

Proposal: allow to use fallback value for BindingElement #12

jwoo0122 opened this issue Aug 18, 2022 · 0 comments

Comments

@jwoo0122
Copy link

jwoo0122 commented Aug 18, 2022

First of all thank you for this awesome package. It really helps me a lot.

Brief explanation of proposal

In this code,

interface Params {
  a: number;
  b: number;
}

function X({
  a,
  b,
}: Params) {
  const x = { a, b }
}

X({ a: 1, b: 2 })
X({ a: 2, b: 3 })

we cannot determine what's the value of x without specifying where X is called, bacause a and b are not deterministic(honestly not only determinstic but also never can hold any value in this lexical scope) before the function is invoked.

However I feel like it is quite useful if we can tell ts-evaluator like "Use 1 as a fallback value of parameter a", then we can predict the value of x, which is actually not accurate, but still we can treat the value like "So x in here is an object with two number property".

Why I ran into this kind of needs

I'm making a web app analyzer, which generate url flow a user can take. Guess this:

https://test.page/path1 -> https://test.page/path2
https://test.page/path1 -> https://test.page/[userId]

https://test.page/path2 -> https://test.page/path1

And this flow is not deterministic, as web app can have various state and under the state the destination url can be changed. See the second line which has userId in the path. It is not important what the exact value of user id is, just using any string or number is fine enough.
So in this context allowing fallback value for BindingElement (or perhaps more several other nodes, which contains the same problem) is useful, I think.

Or, it would be better to provide API to intercept default behavior of evaluating some kind of node, similar to libraries like html-parser? Maybe this is more proper solution cause allowing strange value to evaluate some node would cause unpredictable problem 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant