4 ms·
Glad you like it :) You can bind to arbitrary data regions using named items. For example: cljs.user=> (add-binding-named-item "A1:B2" "binding-id" println)
by theocs 11y ago
Glad you like it :)
You can bind to arbitrary data regions using named items. For example:
cljs.user=> (add-binding-named-item "A1:B2" "binding-id" println)
nil
{:rc 2, :cc 2, :type matrix, :id binding-id}
cljs.user=> (get-binding-data "binding-id" println)
nil
{:rc 2, :cc 2, :type matrix, :id binding-id, :data [[1 2] [3 4]]}
cljs.user=> (set-binding-data! "binding-id" [[2 3] [4 5]])
- moonchrome 11y agowhy use continuation functions (... println) instead of returning values ? Is it because of the underlying JS API is async ? Maybe use something like chans to pipe async values ? Just doesn't seem clojureish to me :D
- moomin 11y agoAuthor of cljs-ajax here, I'd always favour a straight callback. The async stuff is so easy to add on top it doesn't really seem worth it to add the dependency to the library and complicate matters for people that don't want it.
- moonchrome 11y agoI guess that's true - core.async adds a lot of stuff you don't want for something as simple as futures/promises. I wish ClojureScript guys would abstract 'go' macro from core.async in to the clojurescript core, provide well documented protocols that it uses and include implementation for JS Promises by default (then leave core.async to expose chans for those who need channels trough those protocols). Hell if I knew they wouldn't be against doing this I might even do it my self in a few weeks. Considering the async nature of JS it makes sense to provide such a construct as a part of language/standard library.
- theocs 11y agoYou're right about the underlying JS API being async, and that's why those functions are as well. I wouldn't mind adding a blocking variant of these functions, and use async internally to make that happen. But, not there yet.