Skip to content

Multi parameter type guard #37625

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

Closed
5 tasks done
danfma opened this issue Mar 26, 2020 · 2 comments
Closed
5 tasks done

Multi parameter type guard #37625

danfma opened this issue Mar 26, 2020 · 2 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@danfma
Copy link

danfma commented Mar 26, 2020

A little different from #26916.

Search Terms

Multiple Parameter Guard Type

Suggestion

Is it possible to extend the guard type definition to check more than one parameter together?

Use Cases

  • Checking multiple types in React components, without the requirement of verifying each parameter individually, and without the need to use a ternary operator.

Examples

Scenario:

function MyComponent(props: MyComponentProps) {
  // ... some definition
  const hasIconAndDirection = useMemo(
    () => icon && iconDirection,
    [icon, iconDirection]
  );

  return (
    <LinkActionWrapper>
      {hasIconAndDirection && ( // the compiler won't know that these two parameters are checked
        <LinkWithIcon
          icon={icon}
          iconDirection={iconDirection}
          text={text}
        />
      )}
      <div>
        {!hasIconAndDirection && ( // same here
          <StyledLink>{text}</StyledLink>
        )}
      </div>
    </LinkActionWrapper>
  );
);

Option 1: multi-parameter guard type.

function hasIconAndDirection(a: Icon | undefined, b: IconDirection | undefined): a is Icon, b is IconDirection {
  return !!a && !!b;
}

function MyComponent(props: MyComponentProps) {
  // ... some definition

  return (
    <LinkActionWrapper>
      {hasIconAndDirection(icon, iconDirection) && ( // somehow the controller nows that both are defined
        <LinkWithIcon
          icon={icon}
          iconDirection={iconDirection}
          text={text}
        />
      )}
      <div>
        {!hasIconAndDirection(icon, iconDirection) && ( // the compiler knows that maybe they are not defined
          <StyledLink>{text}</StyledLink>
        )}
      </div>
    </LinkActionWrapper>
  );
);

Option 2: Enhance the flow type checking for handling these scenarios

function MyComponent(props: MyComponentProps) {
  // ... some definition
  const hasIconAndDirection = icon && iconDirection;

  return (
    <LinkActionWrapper>
      {hasIconAndDirection && ( // somehow the controller must know that both are defined
        <LinkWithIcon
          icon={icon}
          iconDirection={iconDirection}
          text={text}
        />
      )}
      <div>
        {!hasIconAndDirection && ( // no guarantees here
          <StyledLink>{text}</StyledLink>
        )}
      </div>
    </LinkActionWrapper>
  );
);

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions;
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@jcalz
Copy link
Contributor

jcalz commented Mar 26, 2020

Can you explain how this differs from #26916? Right now it just looks like notation: comma instead of intersection. But it has the same intent: a true return value should narrow multiple parameters. Right?

@RyanCavanaugh RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Mar 27, 2020
@danfma
Copy link
Author

danfma commented Mar 27, 2020

Yes... After looking carefully at that. It looks the same, except for the syntax, and that its type guard is a method, not a simple function. So, it's up to you guys to decide which one should continue. :)

I don't mind closing this one too.

@danfma danfma closed this as completed May 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

3 participants