This is a good post with a lot of ideas to stew on.
I think my only criticism of the current approach in the linked GitHub repo [1] is the use of `eval`, as that could make it tough to utilize in low security/sandboxed environments such as mobile apps and CSP-controlled sites.
I'll save attempting an actual code exercise for later, but my first thought was maybe using JS implicit `this` to your advantage (even while trying to stray away from classes) and using `this[functionName]` to index into it. (You'd still have security concerns with `this` defaulting to `window` or `global`, but you'd avoid the need for `eval` and you can take advantage of the depth of abilities of constructor functions and ES2015 class syntax.)
Yeah the use of eval is purely to get it working today. The ideal would be to just change the JSX parser to place whatever is in the JSX tag directly. That would also give you arbitrary expressions:
If you look at the implementation in the repo, you'll see its actually a little more complex than just eval now (since JSX will pass the actual reference when the tag name starts with a capital letter), but again this was solely to provide something that people could use with their existing Babel implementations and a simple require.
Couldn't you get around using eval by just use an object and register methods on it, instead of global functions, essentially using the object as a namespace? Instead of
/* @jsx ((a,b)=>(eval(a)(b))) */
You would have
/* @jsx ((a,b)=>(MyJSX[a](b))) */
And then just build your functions on top of the MyJSX object?
Ah, I actually missed that last part of your original comment, or I wouldn't have felt the need to comment myself. So much for reading comprehension on my part. ;)
Heh, not exactly. We have a finite amount of hours in the day, and maintaining a JSX implementation is something we just aren't really interested in. You're more than welcome to implement such a thing yourself though, and I'd be the first to retweet it if you did.
FYI, your tonicdev code runner doesn't seem to be working for me.
Whenever I run a code example, I get 5 403 errors one after the other trying to make PUT requests to http://tonicdev.com/new
Sample request:
{"model":{"content":{"package":{"engines":{"node":"4.x.x"},"lastEvaluatedDependencies":{},"dependencies":{}},"title":"","cells":[{"_id":"cells/3f4e1137-79ee-4dbd-b201-ba404a056e0f","content":{"type":"source","text":"/* @jsx console.log */\n\n// Now this is the same as console.log(\"div\", { \"id\":\"my-element\"}, \"hi\");\n<div id = \"my-element\" >hi</div>"}},{"_id":"cells/fd8deede-cfeb-48df-ac0f-740397f61e47","content":{"type":"rich-text","text":"Created from: http://tolmasky.com/2016/03/24/generalizing-jsx/","tag":"p"}...},"evaluationCount":0},"fromNotebook":null,"fromLocation":"http://tolmasky.com/2016/03/24/generalizing-jsx/","embed":tr...}
Regarding the hack to make function calls: if JSX elements start with a capital letter, then the pragma is ignored, and the element name is used as a local variable name instead, e.g.:
A certain portion of programmers seems convinced that currying offers a huge amount of power, and we just haven't unlocked it yet. But I don't think I understand why they feel that way.
Yup, couldn't agree more and that's exactly one of the concerns I'm trying to address in the blog post ("All in all, the resulting effect in my exprience is that currying makes writing code far more pleasurable, but often makes reading code somewhat confusing."). I think the combination of named parameters actually makes it more readable.
Ultimately, isn't this just saying "currying might be great if it was syntactically different from function calls"? JSX is just a hack to make that happen with today's JavaScript tech... It feels like a red herring to focus on it.
Yeah definitely an inspiration (and mentioned twice in the blog post). The main differences (unless I'm mistaken), are the parameter name mapping (which make it easy for differing APIs to interact well) and the idea of separating function application from argument binding, which allows for both re-currying (which actually unifies default parameters under curried parameters) and also for leaving fully-curried functions in a callable state.
I think you mixed some nice ideas with a very weird idea for no good reason. I kept looking for why you want to do this through JSX, but I just didn't find anything convincing.
I like the idea of using the "from" function to rename applied parameters. But that and everything else would be equally possible and a lot less confusing if it didn't involve JSX, no?
JSX provided a convenient syntax to have named parameters in JavaScript. Additionally, it results in nice data structure literals, and finally, you get the same benefits "for free" in a React app by doing this.
The main thing here was that through thinking about JSX, I was able to reach these conclusions. If I had not had to work with this separate syntax, I may not have tried separating function application from function binding. It's kind of like how when you give something a word you can think about it clearer.
For example, one of the issues thats frustrated me in the past is wanting to fully-curry a function but still have it be callable. For example, if you have id = x => x, if you could curry it it would simply become an "always" function. So like, [...].map(<id x = {5}>) (this maps everything to 5 in our case). But with traditional currying, that would simply return 5. Again, you could achieve this curry(id, {x:5}), but I like the visual queue that JSX syntax gives you saying "This is a new FUNCTION with these parameters".
1. Unifying default parameters with curried named parameters: https://tonicdev.com/tolmasky/default-parameters-with-generi...
2. Using generic JSX to declaratively specify JavaScript ASTs: https://tonicdev.com/tolmasky/generic-jsx-for-babel-javascri...