4 ms·

This <input.search /> is a short form of <input class="search" />. You can use either one of those. And `JSX(input.search, {}, null)` does not make sense. But `

This <input.search /> is a short form of <input class="search" />. You can use either one of those. And `JSX(input.search, {}, null)` does not make sense. But `JSX(Input.search, {}, null)` does make sense, yes. In Sciter that will be `JSX(Input-Search, {}, null)` to use Search component from Input module. You are not obligated to use built-in JSX. TS compiler includes its own version of JSX compiler and so it will not hit built-in implementation. "Same deal with hyphens in unquoted object literal keys: it’s not part of ECMAScript now" This was used in TIScript but not in JS, unfortunately. "standard JSX" No such thing. Check forst paragraph of https://www.typescriptlang.org/docs/handbook/jsx.html https://www.typescriptlang.org/docs/handbook/jsx.html

chrismorgan 5y ago
The semantics of the JSX transformation certainly do vary, though there’s a fairly consistent baseline which you’ve broadly matched; yet for all the variations in semantics, the JSX syntax itself is well-defined, and that’s what you’re flouting. In fact, since we’re talking of semantics, one of the ways in which the runtime (post-transformation) semantics vary is a good indication of the problem of special-casing your own syntax: your class syntax transforms into a property named class, but React uses className for the equivalent concept. JSX(input.search, {}, null) makes perfect sense as code and as a concept, though that particular combination of names would be surprising. But suppose it’s something like props.tagName, or library.SomeComponent. As for your JSX(Input-Search, {}, null) being module lookup… I hope that wouldn’t be valid code, and that <Input-Search/> transforms into something other than that, or you’ve got grave problems. But again, this is a point where you’ve deviated from standard JSX syntax in a way that’s far too likely to cause trouble down the road. Why not rather use Module:Component or module.Component, both of which are syntactically valid JSX? (I dunno if these modules are global or have to be imported or whatever, so I don’t know what’s most appropriate.) Concerning hyphens in keys: I’m referring to what you’re suggesting as a possible addition to your brand of JavaScript. I’m suggesting that it would be better if you resisted the temptation to alter JavaScript at all, beyond possibly standard JSX syntax.

chrismorgan 5y ago

The semantics of the JSX transformation certainly do vary, though there’s a fairly consistent baseline which you’ve broadly matched; yet for all the variations in semantics, the JSX syntax itself is well-defined, and that’s what you’re flouting. In fact, since we’re talking of semantics, one of the ways in which the runtime (post-transformation) semantics vary is a good indication of the problem of special-casing your own syntax: your class syntax transforms into a property named class, but React uses className for the equivalent concept. JSX(input.search, {}, null) makes perfect sense as code and as a concept, though that particular combination of names would be surprising. But suppose it’s something like props.tagName, or library.SomeComponent. As for your JSX(Input-Search, {}, null) being module lookup… I hope that wouldn’t be valid code, and that <Input-Search/> transforms into something other than that, or you’ve got grave problems. But again, this is a point where you’ve deviated from standard JSX syntax in a way that’s far too likely to cause trouble down the road. Why not rather use Module:Component or module.Component, both of which are syntactically valid JSX? (I dunno if these modules are global or have to be imported or whatever, so I don’t know what’s most appropriate.) Concerning hyphens in keys: I’m referring to what you’re suggesting as a possible addition to your brand of JavaScript. I’m suggesting that it would be better if you resisted the temptation to alter JavaScript at all, beyond possibly standard JSX syntax.