View Integration with Backbone about phosphor HOT 7 CLOSED

A bit more about the questions we have.

• It seems like Phosphor Components are View-y type things. This seems to
  overlap highly with what backbone Views do. Do these things solve the same
  issue?
• One of the main ways we use backbone is just for the model sync. Would it
  make sense to integrate a phosphor component with backbone by wrapping the
  backbone model only in a TS model class (hidding the details of backbone).
  In this approach, we would never use backbone views at all.

Thoughts?

On Fri, Jul 17, 2015 at 4:08 PM, svurens [email protected] wrote:

@ellisonbg https://github.com/ellisonbg and I were talking earlier
about possibly using Phosphor to replace Backbone's View class. Would that
currently be possible, and if so, how would I go about doing that?

—
Reply to this email directly or view it on GitHub
#45.

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

from phosphor.

any objection to moving discussions to the Phosphor Gitter?

https://gitter.im/phosphorjs/phosphor

from phosphor.

I am on there now...

On Fri, Jul 17, 2015 at 4:43 PM, S. Chris Colbert [email protected]
wrote:

any objection to discussions to the Phosphor Gitter?

https://gitter.im/phosphorjs/phosphor

—
Reply to this email directly or view it on GitHub
#45 (comment).

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

from phosphor.

The latest version of backbonejs (1.2) which is used in the current development version allows for custom views that don't require jquery. You can check out projects such as D3View and NativeView but the key is that you can use the DOM manipulation program of your choice. Creating a phosphor view would be easy.

In ipywidgets, we made the base widget class a mixins, in order to let users create custom widgets with other implementation of backbone.View. Besides, widget.js and manager.js actually don't require jquery anymore and only perform native DOM api calls - and we don't use View.$el anymore since it is specific to the jquery views... I am actually using a flavor of D3View myself.

IMO, backbonejs and its very large user base enable custom widget authors who may not want to adopt a specific framework, or to learn phosphor. Besides, dropping it would have an enormous migration cost for us.

In jupyter-widgets/ipywidgets#73, I proposed to add an example of use of NativeView to present how these mixins can be used. I could also add a simple example using D3View if you like.

from phosphor.

closing this since we are conversing offline

from phosphor.

Can you post a summary here?

On Fri, Jul 17, 2015, 20:33 S. Chris Colbert [email protected]
wrote:

closing this since we are conversing offline

—
Reply to this email directly or view it on GitHub
#45 (comment).

from phosphor.

It expanded into a larger conversation about phosphor and design. Here were my take aways:

On Models:

• We should build model interfaces and implementations of those model interfaces using TypeScript.
• Models should have API to return submodels - the ContentManager should be able to return Notebook and TextFile models, the Notebook model should be abel to return Cell models, etc.
• Those model objects may be impleented internally using backbone models, Google realtime API or existing jupyter web services.

On Views:

Chris identified 3 main ways of buidling Views:

• Phosphor Widgets
• Phosphor Compoments (that use the virtual DOM)
• "Plain DOM nodes" Because we can't use web-component custom elements, for now we will end up wrapping plain DOM nodes in simple Typescript classes.

However, the problem with the "plain DOM node" approach is that there are a common set of methods and events on these types of objects, such as those related to lifecycle, attaching, detaching, etc. Chris mentioned the possibility of having Phosphor.Widget inherit from a new common base class that does CSS based layout, but that has the base lifecycle methods/events.

We will likely use intermediate ViewModel classes that adapt the View and Model parts.

from phosphor.