search

ramnathv / htmlwidgets

HTML Widgets for R
http://htmlwidgets.org
Other
790 stars 207 forks source link

Making widgets talk to each other! #86

Open ramnathv opened 9 years ago

ramnathv commented 9 years ago

I have been experimenting with the ability to use widgets as components and then allow them to communicate with each other.

Here are some examples

  1. Life Expectancy Choropleth + Line
  2. Datamaps + Chroniton
  3. Datamaps + Morris + Sortable

The first example uses shiny, while the second does not.

In the case of Shiny, I am using Shiny.onInputChange to trigger changes and communicate back to the server from the client on mouseover. In the second example, I am directly manipulating the datamap from the callback code of the chroniton widget.

The more I think about this, I believe that something like a pubsub design pattern will be helpful here. htmlwidgets can provide basic pubsub infrastructure and widget authors can provide callbacks that allow users to broadcast data on certain events. In a similar vein, widget authors can also expose callbacks that allow a widget to listen to certain events and trigger a change.

By following some conventions regarding how these events are named, it would be possible for widgets to talk to each other using pubsub. Currently, this idea is still very hazy in my mind, but I wanted to put it out here so that it can trigger a broader discussion.

In the shiny case, things are easier, since Shiny.onInputChange provides a simple pubsub mechanism. I am thinking of a more general mechanism that will work with and without Shiny.

@jcheng5 I would really appreciate any thoughts you have on this, given your experience working with javascript libraries. @jjallaire @timelyportfolio @yihui Any thoughts/comments on this idea would be welcome, as I think it would be a very powerful way forward for htmlwidgets to create a componentized architecture.

ThomasSiegmund commented 8 years ago

Hi all,

I'm very happy about crosstalk. IMHO this is the next big step for the Shiny and htmlwidgets ecosystem.

I have now added support for crosstalk in D3TableFilter. There is a demo app combining a d3scatter and a d3tf widget. Selecting dots in the plot highlights corresponding rows in the table and vice versa.

I guess it will take a while and a few good apps to figure out all the semantics. The table may allow to filter out rows - what should happen to the dots in the graph? Should we have an additional crosstalk variable ("hidden") ?

Thanks a lot @jcheng5 !

timelyportfolio commented 8 years ago

@jcheng5, @ramnathv any updates on this?

ramnathv commented 8 years ago

@timelyportfolio mobservable has changed their API significantly. I am reworking things using the new version and will put it out here. There are still several outstanding issues in terms of the order in which observables get evaluated. Based on conversations with @jcheng5, it is bound to be much harder doing everything client side. But I think there is scope for an effective solution.

timelyportfolio commented 8 years ago

@ramnathv I wondered if the change to mobx would throw a kink into the solution, and I guess the answer is yes. As always, I am very interested and happy to help in any way possible.

jcheng5 commented 8 years ago

I should probably write up a blog post or something about the current state of things--I've had the same conversation privately with a number of people. Basically there's several different directions things are growing, each of which is ideal for a particular kind of widget user (depending on how skilled they are in JS, how much time they want to spend writing custom code, and how much R runtime support [Shiny] is needed).

I had told @cpsievert and @hafen (and possibly @ramnathv) I was having second thoughts about the crosstalk approach, but subsequent conversations with @jjallaire have convinced me that it's an important piece of the story. I'm tentatively planning on investing further in crosstalk over the next few months, with an eye towards a CRAN release (or merging into htmlwidgets master?) and getting several more htmlwidget packages working well with it.

timelyportfolio commented 8 years ago

@jcheng5 + @ramnathv thanks so much for the updates. I'm just a little excited :) and anxious to test and experiment. I stopped the crosstalk earlier this year to make sure I wasn't headed in the wrong direction.

jcheng5 commented 8 years ago

@ramnathv "The order in which observables get evaluated" sounds bad--I believe it shouldn't be a problem if you follow some simple (well, simple-ish) rules. This was one of the main topics of my 3 hour reactivity tutorial at ShinyDevCon in January. We should talk about this if this isn't something that mobservable considers a solved problem.

ramnathv commented 8 years ago

@jcheng5 the problem is not with how mobservable deals with things. it is more about syntactic sugar that i was trying to add that automatically creates observables underlying elements in the dom. so the order issue arises due to the dom, not because of the underlying library itself. I will create a set of simple examples to illustrate the issue.