When I read the above, I fear for the new devs. The number of concepts to grasps and the level of parsing and mind bending to do is incredible.
I used to teach code, before arrow functions and React. And I am convinced I would have lost some students to this snippet, especially the "= () =>" segment.
Are we gone too far syntactically for the sake of compactness rather than understandability, allin the name of (fake, IMO) readability?
Some of that shifts with syntax highlighting: drawing the eyes to which bits are more specifically related. The arrow => should highlight as a single operator (just as >= does), for instance. Most people call these "arrow functions" so thinking of "=>" as the arrow operator is a habit that quickly builds.
They are controversial and everyone has different opinions, but I also think this is where programming ligatures come in extremely handy. When => looks more like ⇒ and is even more obviously an arrow, I think that also starts to make it easier to visually "parse" the flow of code like that.
For what it is worth, arrow functions weren't added solely for compactness, but also to fix some historic issues with classic function syntax. (Lexically scoped `this` versus caller scoped `this` being the big one.) A new type of function syntax was desired anyway for those reasons, and the compact syntax was the icing on the cake.
I haven't had the pleasure of teaching such things to students at this point in my career, but I have given a hand to many a junior developer to grasping some of these ideas and I don't think it is that tough, though it can be a shock/surprise if the last JS you touched was many years before. Especially if you are trying to also learn what JSX and/or TSX add on top of all the changes in ES2015+.
No. That's perfectly normal syntax you would use every day. It is not sophisticated or special.
Also, consider functional languages like Haskell or whatever. Their syntax is exceptionally foreign for users of C-like languages, and so are the concepts. Still, they're (relatively) widely used.
If you work with JSX daily, which 99% of React developers do, this is not hard to grok. It's a very typical functional composition pattern in React. Since this framework is targeted at those who want to use React, and presumably already use it, I don't see the issue. It's a snippet to show how Reactivated lets you use the React ecosystem, not how to use React - that's what the docs are for.
I’m not sure that brand new devs who have trouble reading standard JSX, are exactly the target market for a bleeding edge project that combines two popular frameworks together.
I think the target market is experienced people who want to use both react and Django, and feel that this project saves time on conceiving and writing their own integration.
Compactness and understandability are the same thing on a large scale or under time pressure. This example is definitely loaded, but compared to more wordy alternatives it just cuts to the chase.
Extended code reads like a narrative journalism. “It was an end to a long dark night and trees shyly stayed in a fog when options in a full entirety of their generous content got passed into a pure functional instance of a select tag”.
Maybe we can find consensus by avoiding the extremes.
"Extended code" as you name it is certainly bad with regards to explicitness, while extreme compactness like (some) one liners are as bad as the former but with regards to readability.
> export const Flavor = () => <Select options={flavors} />;
When I read the above, I fear for the new devs. The number of concepts to grasps and the level of parsing and mind bending to do is incredible.
I used to teach code, before arrow functions and React. And I am convinced I would have lost some students to this snippet, especially the "= () =>" segment.
Are we gone too far syntactically for the sake of compactness rather than understandability, allin the name of (fake, IMO) readability?