Very good article, it is easy to predict great use cases for JSX concept in the future.
I proposed the idea of using JSX as angular2 templates. They didn't like it and I think the React competition was an important factor for that.
Generalizing JSX: Delivering on the Dream of Curried Named Parameters
11–20 of 29 posts
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#12I 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() (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".
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#13A 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.
It's just a different way of structuring.
api = new Api('http://my.cool.api')
api.get('/it')
api.post('/it')
// connect = rootUrl => method => endpoint
api = connect('http://my.cool.api')
get = api('GET')
post = api('POST')
get('/it')
post('/it')
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#14This 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…
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 wa…
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))) */
/* @jsx ((a,b)=>(MyJSX[a](b))) */
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#15Very relevant https://github.com/substack/hyperx
I code in react without jsx and webpack. I recommend hyperx for your code. Hopefully new modules can be built out of this one.
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#16Earlier quoted context omitted.
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 wa…
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?
Yep, that's essentially where I was leading.
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#17Earlier quoted context omitted.
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?
Yep, that's essentially where I was leading.
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. ;)
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#18In case anyone is curious, I have since posted some additional thoughts:
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...
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#19Seeing 'xml' trees reminds me of a child from ML and XSLT...
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#20Regarding 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.:
transform("hi!")
Foo({id: "my-element"}, ["hi!"])