Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I’m a fan of the “Generic type arguments in JSX elements” - ran into a case where I needed it a few months ago. They’ve always had a workaround, but this is more concise.


sort by: page size:

If you use JSX with typescript you effectively get type-checked html attributes.

JSX is typed, you get all the benefits of intellisense and type safety. It even supports generics.

This is a neat syntax, but it doesn’t seem at all typesafe (typesafety was the main benefit of JSX over the various string templates that came before it).

TypeScript also have JSX support. It's in master right now.

The one place where react typings are disappointing to me is that all elements are typed as JSX.Element, meaning you can’t assert a specific type of child element. Usually not a big deal but would be useful in a number of cases.

Haha, I have spent my fair share of time procrastinating over what a type-safe JSX alternative would look like for React.

The most ergonomic solution (well, atleast for me) has been their old factory API upon which I layered a set of convenience utilities [1]. I have been trying it out in a hobby project and I find the reduction of className boilerplate, elimination of closing tags etc. quite productive. And unlike alternatives like react-pug etc. I don't have to compromise with type checking of attributes.

I'll probably release it as a library after doing some performance evaluation and if needed, wrapping it in a babel-macro [2] that eliminates the runtime overhead.

--

[1] Example in CodeSandbox: https://codesandbox.io/s/pedantic-shape-lq9q9?file=/src/reac...

Code in github gist: https://gist.github.com/lorefnon/53377e4d6a6b13adbcfa155f486...

[2] https://github.com/kentcdodds/babel-plugin-macros


Also, why haven't we just standardized on JSX being sugar for {tag,attrs,children} literals? Then it can be manipulated at runtime however anyone wants, and we would have had so much fewer problems with basically everything around it.

Also, Typescript type checks the JSX. This was the big thing that convinced me to start using TSX was typed views. (I've not been using React, so I've been using preserve behavior and Babel to feed the Virtual DOM library I am using.)

Okay fair but I still dislike the JSX syntax :)

The big win of JSX is that you get full type checking on your templates as well as your code if you use Typescript. On bigger projects this is a huge help.

And you can eschew the JSX syntax entirely with nothing but a small cost to dev ergonomics.

A company I worked at had a O(1 MLoC) React frontend with no JSX at all for a long period of time due to the Typescript compatibility issue, just `export const El = React.createElement`


Glad to see someone pints this out. That’s the main reason I use React + Typescrip. JSX is an extension of javascript and can be fully checked while any template language is a custom invention that it’s hardly toolable.

Would be nice to see JSX syntax become standardized. Clearly lots of people like it.

Huh. Well, my only defense is that I would never even try to write JSX like that anyway - the actual JS in my JSX templates is basically just Array.map calls.

A lot of people still use it to support JSX syntax in React.

Also to remove Typescript types without type-checking (the type-checking is often done in parallel, for speed).


What I really like about JSX is when you use it with TypeScript, you get type checking in your view layer all the way to the "top". When switching back to things like MVC Razor or Angular that have a separate template, I often hit bugs that a type system would have prevented.

Strongly agree. I just don’t get the hate for JSX.

JSX is objectively better than than the scores of templating systems out there. You get much more: type checking, use of JS for logic, and no need to learn yet custom arcane syntax. If anything, I think JSX is not used and supported enough.

In the general sense, JSX is just syntactic sugar for function composition. That it works well for html-style components is a side effect; it could certainly be used for more than that.

I wish languages like Typescript would support JSX natively, with absolutely to dependency on any React-like library. Let me declare a function using JSX, e.g.,

    type Mode = “upper” | “lower”
    const capitalize = (str: string, mode: Mode) => mode === “upper”? str.toUpperCase() : str.toLowerCase()
    const join = (mode: Mode, …arr: string[]) => arr.map(str => <capitalize {{ str, mode }}/>).join()

    const joined = <join mode=“lower”>Bon Jovi /> // “bonjovi”

> JSX is 1,000% magic syntax, and anyone telling you otherwise is trying to sell you something.

> It looks, feels, and acts wrong in ways that Svelte or Vue templates (and most other templating systems) don’t, to me.

My biggest example of this (and it drives me crazy) is when mixing Typescript generics in TSX files: you often have to do ridiculous boilerplate like `<T extends any>` because otherwise `<T>` would be recognized as JSX and blow up the syntax tree. Hoorah for the context-sensitive grammar.

Typescript is what "No magic syntax" looks like: all it takes to get usable javascript is to parse the TS AST, remove the TS specific nodes, and serialize the tree back to text. There are a few exceptions like enums but they're not core features and you can go your entire career without needing them. Meanwhile the JSX ecosystem is full of crap like emotion and styled-components that need babel plugins to support features like component selectors. SMH


I've written an in depth blog post on "generic jsx", which turns JSX into function bind/currying syntax that would work fine in any framework (or not framework at all, as we currently use it).

http://tolmasky.com/2016/03/24/generalizing-jsx/

We use this generic-jsx in DemoKit: https://github.com/runkitdev/demokit , and it's really cool because you can do fancy stuff like:

      // Curry your JSX tags!
      const wordmark = <span style = "font-face:custom; font-weight:bold" />;

      .... <wordmark>hello</wordmark>
next

Legal | privacy