Stricter interfaces/literal types #6352

Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   SuggestionAn idea for TypeScriptAn idea for TypeScript

   Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.This issue needs a plan that clarifies the finer details of how it could be implemented.

   on Jan 5, 2016
2. RyanCavanaugh commented on Jan 5, 2016

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Jan 5, 2016

   Member

   More actions

   Obviously we'd need a description of some desired semantics to make a call, but I think the bar here is relatively high. The type of style is going to be some named interface if it's of any reasonable size, at which point you could write

   interface SupportedStyles { backgroundColor?: string }
   function applyStyles(el: Element, style: SupportedStyles) {}
   const styles: { [key: string]: SupportedStyles } = {
     header: {
       backroundColor: '#eee', // Error issued here
     },
   };
3. ewinslow commented on Jan 5, 2016

   

   Evan Winslow (ewinslow)

   on Jan 5, 2016

   Author

   More actions

   That seems like a reasonable workaround for now. Thanks. I'll come back with any more relevant info after I try that.
4. ewinslow commented on Jan 22, 2016

   

   Evan Winslow (ewinslow)

   on Jan 22, 2016

   Author

   More actions

   Ryan Cavanaugh (@RyanCavanaugh) So I tried out your suggestions, but I get an error when I try to access styles.header

   interface StyleProps {backgroundColor: string;}
   function applyStyles(el: Element, style: StyleProps) {}
   
   const styles: {[key:string]: StyleProps} = {
     header: {
       backroundColor: '#eee',
     },
   };
   
   // Error: unknown property "header" on {[key:string]:StyleProps}
   applyStyles(document.getElementById('#header'), styles.header);

   If I switch to styles['header'] it works, but that isn't quite what I want either.
5. RyanCavanaugh commented on Jan 22, 2016

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Jan 22, 2016

   Member

   More actions

   You could do this? I'm not sure I'm handling all your use cases here, though:

   interface StyleProps {backgroundColor: string;}
   function applyStyles(el: Element, style: StyleProps) {}
   
   const styles = {
     header: {
       backgroundColor: '#eee',
     } as StyleProps
   };
   
   // OK
   applyStyles(document.getElementById('#header'), styles.header);
6. ewinslow commented on Apr 18, 2016

   

   Evan Winslow (ewinslow)

   on Apr 18, 2016

   Author

   More actions

   Circling back: {foo: 'bar'} as StyleProps passes typechecking, since I think the as StyleProps is just a cast, right? It's effectively the same as {header: <StyleProps>{foo: 'bar'}}.

   The workaround I'm thinking of at this point is to just have a styleProps function that takes StyleProps argument:

   function styleProps(props: StyleProps) { return props; }
   

   Then this will be type-checked:

   const styles = {
   header: styleProps({
   backroundColor: '#000', // Error, unknown property in object literal
   }),
   };

   It's just unfortunate that this kind of boilerplate is required since it relies on callers being well-behaved.

   It doesn't matter too much in the StyleProps use-case since the issue of passing unknown properties is relatively low impact. However, this becomes more "interesting" in a security-sensitive context where I want to whitelist what properties can be assigned to a dom node:

   interface DivProps {
     style?: StyleProps;
   }
   function div(props: DivProps): HTMLDivElement {}
   
   div({onclick: 'alert("pwnd")'}); // Error. Yay! no XSS.
   
   const props = {onclick: 'alert("pwnd")'};
   div(props); // No error. XSS :(
   

   That being said, I suppose the only truly safe way to defend against this kind of thing is runtime whitelists, since all the type-checking can just be trivially defeated by introducing any. It'd just be nice if more of these checks could happen automatically at compile time.
7. laszlojakab commented on May 11, 2016

   

   Laszlo Jakab (laszlojakab)

   on May 11, 2016

   Last edited by laszlojakab

   More actions

   Maybe the same problem related to union types:

   interface X {
   
   }
   
   interface Y {
       z: Z;
   }
   
   interface Z {
       a: string;
       b: string;
   }
   
   let z: Z = { // Error, which is ok: "Type: '{}' is not assignable to type 'Z'. Property 'a' is missing in type '{}'."
   };
   
   let foo: X | Y = {
       z: { // Not an error but it should be: if foo is X then it shouldn't contain field 'z', if foo is Y then 'z' field should contain 'b'
           a: "abc"
       }
   }

   Can I force the compiler to show an error message if "b" field is not provided at "foo.z.b"?

   👍React with 👍1Reacted by dlants
8. RyanCavanaugh commented on Jul 20, 2020

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Jul 20, 2020

   Member

   More actions

   This is an upstream wish for exact types or the "non-casting type assertion" operator
9. Ryan Cavanaugh (RyanCavanaugh)

   closed this as completedon Jul 20, 2020