Generalizing JSX: Delivering on the Dream of Curried Named Parameters
1–10 of 29 posts
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#2Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#3A 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.
E.g. `sumList = reduce(sum)`
It has a variety of drawbacks though, like being harder to inspect at runtime, and arguably harder to read.
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#4A 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 mostly allows you to write extremely short code. E.g. `sumList = reduce(sum)` It has a variety of drawbacks though, like being harder to inspect at runtime, and arguably harder to read.
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#5Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#6"Dream of Curried Named Parameters" What dream, this is a daily reality in OCaml.
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#7I 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.)
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#8This 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…
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.Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#9I 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?
Re: Generalizing JSX: Delivering on the Dream of Curried Named Parameters
#10A 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.
http://hyegar.com/2016/03/22/simple-timeouts/
In it the timeout function only takes one arg for its timeout wrapped function, so how do we use functions with more than 1 arg? Via currying