Comments (4)
Does this keep the behavior of returning a special value (a uuid) which gets replaced?
Do we need to design in other interactive features at the same time, e.g.
- callbacks when something is clicked on (if there is anything special about that)
- a way for an R program to query the selection or filters
- a way to link diagrams between cells (again, if any special handling is needed for this)
- more generally, variables in R that represent JavaScript objects, and vice versa. (Yes I know, getting kind of wacky, just thought I'd throw it out there.)
Or are these separate concerns? I.e. is this ticket just about a modular plug-in design for javascript libraries, or should we also address the interactive features we want at the same time?
from rcloud.
Does this keep the behavior of returning a special value (a uuid) which gets replaced?
For now, it will be easier to keep the uuid-passing kludge, because it forces knitr to actually create a div which we can populate appropriate.
I.e. is this ticket just about a modular plug-in design for javascript libraries, or should we also address the interactive features we want at the same time?
I'd like to understand the design space a bit better before deciding if I want to hardcode these features, but let's say they're all up for discussion now. My original idea was to build the entire infrastructure on top of the two basic "RPC" primitives above:
- Javascript calling R: an asynchronous call that passes a list of values to some R closure. The call would look exactly like the calls on
htdocs/js/rcloud.js
: parameters and a continuationk
. This would look idiomatic in the world of async javascript calls everywhere, so there should be no additional impedance mismatch. - R calling Javascript: a blocking call that waits for a result from the Javascript side, likely implemented on top of the OOB message functionality of RServe. Again, this would look idiomatic in the R world, so no complications in the way R code would be structured should arise. There is a problem in the Javascript side, which is there's no way to enforce at the language level that some result will actually be sent back to R, and so it might become too easy to write buggy code that locks the R evaluator.
Ideally, the interactive features you describe above would be written using these two basic primitives, and exposed in rcloud.support
and htdocs/js/rcloud.js
respectively, so RCloud package writers could use the API on both sides of the system.
Your "way for an R program to query the selection or filters" list item is certainly the kind of thing we want to allow, but I'd like to design the primitives that RCloud package writers could use, rather than figure out the universe of all such possible requests.
from rcloud.
Here's partial progress for Javascript calling R, using the new support for object capabilities in rserve and rserve-js. Look at the code in basic.js and in oc.init.R.
I'm really happy with how clean the code looks. It's still callback pyramids, but there's nothing we can do specifically about that. The cool part is how ocaps on the R side transparently become async calls on the Javascript side.
from rcloud.
Since commit 4ae113c, this is enabled. See password.R
for a trivial example of R+Javascript interaction that can be moved entirely into a library. Lots of cleaning up left to do on the source tree yet, but closing the issue for now.
from rcloud.
Related Issues (20)
- display host in HTTP error messages
- Open in GitHub should also be disabled on view page
- option to set notebook name when creating new notebook
- Support GitHub App API
- can't add tag to current version
- notebook.R and non-R code
- error in merge
- should the author also be grayed if recent notebook is hidden?
- RCloud as a Package HOT 1
- allow use.gist.user.home with gist service login
- rcloud.jupyter only supports older jupyter packages HOT 1
- progress bars a mess
- view.html?source=1
- Cell commands, or at least "run cell", for view.html
- I been going into hacked fake at&t website HOT 1
- add Export Notebook as R source file to view.html
- passing working directory between languages
- "reload" button for notebook tree
- enhance rcloud.encrypt/rcloud.decrypt to handle user and group keys
- upload to working directory HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rcloud.