Community Feedback Request - Release a 2.0 if React removes the patents clause?

[sccolbert]

One of the big reasons that Phosphor includes its own virtual DOM implementation, is because of React's patents clause. In the wake of the Apache foundation forbidding the "react+patents" license in dependencies, Facebook relicensed RocksDB as dual Apache/GPL. It's reasonable to assume that React will follow suit:
facebook/react#10191

Should that happen, what is the communities feedback on releasing a Phosphor 2.0 which does not include @phosphor/virtualdom and replaces all internal uses of that package with React?

If we do this, it will be the first external runtime dependency for Phosphor.

cc @ellisonbg @jasongrout @birdsarah @bollwyvl @jdetle @blink1073 @afshin @ian-r-rose @gnestor

[gnestor]

I think this would be a really great thing! It would save @sccolbert a ton of work and open up the project to a lot more contributors from the React community. It would also allow bundled extensions to make use of open source React components. It could also make it more straight-forward to provide and consume JupyterLab UI components (e.g. dropdown, right-click menu, toolbar, etc.).

[jdetle]

I agree completely with grant. Should it happen it makes total sense to switch over.

On Mon, Jul 17, 2017 at 12:23 AM Grant Nestor ***@***.***> wrote: I think this would be a really great thing! It would save @sccolbert <https://github.com/sccolbert> a ton of work and open up the project to a lot more contributors from the React community. It would also allow bundled extensions to make use of open source React components. It could also make it more straight-forward to provide and consume JupyterLab UI components (e.g. dropdown, right-click menu, toolbar, etc.). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#302 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKcARroqpR6j3IiqEucyvvWfz8icWay7ks5sOu_PgaJpZM4OZb_a> .

-- Have a wonderful day, John J. Detlefs

[blink1073]

I also concur with Grant.

[afshin]

I agree with @gnestor as well

Even without the benefit broader community uptake or support, these gains are themselves nontrivial:

• 100% inter-compatibility guarantee when functional components are exported
• Free high-end implementation of virtual DOM whose ongoing development comes from upstream and is reliable

[jasongrout]

What components use a VDOM implementation right now? The menu bar, the tab bar, and the command palette?

One thing not addressed in the above notes: of all the VDOM implementations out there, why React specifically? For one, it clearly has the largest community adoption, and presumably the greatest momentum. It does seem like we can't make the vdom implementation swappable because of the hard dependency.

Thinking of embedding one of these phosphor components in another page: Are there any problems with having React as a dependency that interfere with other uses of React on a page? Does React require being a singleton, so there would need to be some sort of deduping and possible version conflicts if React is used elsewhere on the page?

[sccolbert]

What components use a VDOM implementation right now? The menu bar, the tab bar, and the command palette?

CommandPalette, Menu, MenuBar, and TabBar.

why React specifically

For all the reasons you mention.

Are there any problems with having React as a dependency that interfere with other uses of React on a page?

React would just need to be importable through whatever bundler you choose. We wouldn't be shipping our own copy.

[jasongrout]

React would just need to be importable through whatever bundler you choose. We wouldn't be shipping our own copy.

Oh right, I forgot you aren't distributing a webpack bundle.

[gnestor]

Are there any problems with having React as a dependency that interfere with other uses of React on a page? Does React require being a singleton, so there would need to be some sort of deduping and possible version conflicts if React is used elsewhere on the page?

Yes, having more than 1 version of React loaded on a page can definitely cause issues. However, seeing as though we are using webpack to bundle everything together (including 3rd party extensions.), we should be able to dedupe and control which version of React is provided.

[ellisonbg]

I would be in favor of using React if the license change follows.

…

On Mon, Jul 17, 2017 at 7:30 AM, Grant Nestor ***@***.***> wrote: Are there any problems with having React as a dependency that interfere with other uses of React on a page? Does React require being a singleton, so there would need to be some sort of deduping and possible version conflicts if React is used elsewhere on the page? Yes, having more than 1 version of React loaded on a page can definitely cause issues. However, seeing as though we are using webpack to bundle everything together (including 3rd party extensions.), we should be able to dedupe and control which version of React is provided. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#302 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0E00_m9jFnNyCSRUwolnL6LvIh09ks5sO2_7gaJpZM4OZb_a> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]

[birdsarah]

Anything that deduplicates effort seems like a good thing.

We have been building up a collection of ui elements that we call ui-kit that all rely on VDom. We have the intention to make it public, just haven't yet. This has been a decent amount of work and if there's a chance this means that we could move to something from a larger community effort that would be great.

[ellisonbg]

It appears that Facebook has reached a no-op decision:

https://code.facebook.com/posts/112130496157735/explaining-react-s-license

I am very disheartened by this. The most painful part is that the post appears to clarify Facebook's intent to use the patent clause as a weapon in their overall patent strategy. I would summarize their position in this way, "if you are feeling uncomfortable with the react.js patent retaliation clause, then good, cause that is why it is there."

I will be working with NumFOCUS folks this week to figure out a path forward.

[sccolbert]

Yep. Saw that last night :(

It seems the wider community is also realizing they weren't paying close enough attention to the clause. https://news.ycombinator.com/item?id=15050841

[sccolbert]

https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2

[sccolbert]

In light of this, I think the safest way forward right now is to not adopt React in Phosphor.

[ellisonbg]

https://code.facebook.com/posts/300798627056246

[blink1073]

Reopening in light of the license change.

[jjrv]

@phosphor/virtualdom is currently about 940 lines of code, of which maybe a half is element, attribute and property names. Doesn't sound so nice to depend on React just for that :/

For me the best things about PhosphorJS are TypeScript and that it doesn't bring in junk like lodash, jQuery, React and dozens of totally useless and incompetent left-pad style packages. How much extra work would it be to design so that React is the "official" vdom implementation, but 3rd parties could replace it?

Then there's Vue, Mithril and Moon or other bloated alternatives like Angular or Aurelia. Hopefully PhosphorJS could be impartial to such choices.

Dojo 2 will use maquette which is also all TypeScript and with a codebase about the size of the current @phosphor/virtualdom. Not saying it should be chosen instead, but if there's a suitable abstraction in place in PhosphorJS, for example I could maintain a phosphor-maquette package to replace React in my own projects.

[jdetle]

What would it take to have phosphor widgets that are compatible with react, while still maintaining widgets that are compatible with the phosphor vdom?

[sccolbert]

@jdetle not worth the effort.

[blink1073]

@jjrv, an API compatible virtual DOM implementation (like preact-compat or a shim on top of something like maquette) could be swapped out at bundle time using something like require.alias in WebPack.

[jjrv]

@blink1073 in that case it would be nice if a subset of React API not much larger than the current vdom API was used. Any necessary shim could then be kept small. I'm sure PhosphorJS would also work great in some Angular projects and it would be silly for them to also include React.

[sccolbert]

To be clear, we're only talking about @phosphor/widgets here. The rest of the Phosphor packages don't depend on vdom.

[sccolbert]

@jjrv It's also silly for me to maintain a separate vdom library at this point, given that React is more complete, has a large community, several useful third part components, and now an MIT license.

[veeramarni]

Is it suppose to work with react dom now or still using a separate vdom?

[ellisonbg]

In JupyterLab we have begun to use react for all virtual DOM rendering. Phosphor is still shipping its own vdom library that is used internally for rendering some elements. The two approaches play together just fine. The only caveat is that JSX/TSX can only be pointed to a single implementation in a given build. We have talked about a couple different ways of handling this in phosphor - but haven't finalized the approach. The main questions are if we want to try to keep backwards compatibility or release a phosphor 2.0 that break the existing vdom APIs. I will let @sccolbert comment more on that aspect. In terms of which virtual DOM library you should use in your own code, react is a great baseline, but you could also consider others based on your needs (features, API, performance, react compatibility, etc.)

…

On Mon, Jan 15, 2018 at 8:21 AM, veeramarni ***@***.***> wrote: Is it suppose to work with react dom now or still using a separate vdom? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#302 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0BRJZ7Xgj-Z51Epz0MBh0Atx9pytks5tK3rvgaJpZM4OZb_a> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]

[veeramarni]

Ok, do you see any problem implementing this way?

export default class ReactWidget<TProps = {}> extends Widget {
  private _cssClass = style({
    backgroundColor: appBackgroundColor,
    display: 'flex',
    flexDirection: 'column',
    minHeight: '50px',
    minWidth: '50px',
    padding: '4px'
  });

  constructor(private component: React.ComponentClass<TProps>, private props?: TProps) {
    super();
    this.addClass(this._cssClass);
  }

  protected onAfterAttach(_: Message): void {
    this.update();
  }

  protected onBeforeDetach(_: Message): void {
    ReactDOM.unmountComponentAtNode(this.node);
  }

  protected onUpdateRequest(_: Message): void {
    ReactDOM.render(
      React.createElement(AppContainer, {}, React.createElement(this.component, this.props)),
      this.node
    );
  }
}

[ellisonbg]

We have a helper class in jupyterlab that manages this: https://github.com/jupyterlab/jupyterlab/blob/master/packages/apputils/src/vdom.ts#L29 The main ideas needed are there and you can modify based on your needs (like remove our model stuff if not relevant). But yes, you are on the right track! Because we have some of that code over in jupyterlab, and we are working on react stuff there, you might want to post that code snippet on this issue: jupyterlab/jupyterlab#3493 Cheers, Brian

…

On Mon, Jan 15, 2018 at 1:42 PM, veeramarni ***@***.***> wrote: Ok, do you see any problem implementing this way? export default class ReactWidget<TProps = {}> extends Widget { private _cssClass = style({ backgroundColor: appBackgroundColor, display: 'flex', flexDirection: 'column', minHeight: '50px', minWidth: '50px', padding: '4px' }); constructor(private component: React.ComponentClass<TProps>, private props?: TProps) { super(); this.addClass(this._cssClass); } protected onAfterAttach(_: Message): void { this.update(); } protected onBeforeDetach(_: Message): void { ReactDOM.unmountComponentAtNode(this.node); } protected onUpdateRequest(_: Message): void { ReactDOM.render( React.createElement(AppContainer, {}, React.createElement(this.component, this.props)), this.node ); } } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#302 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0JuTMt3z9d8ZJIzXhqGCfRH0_Q2Uks5tK8ZEgaJpZM4OZb_a> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]

[lukehutch]

Why not use Inferno instead? Its it is smaller and much faster than React, and in particular its virtual DOM diff implementation is much faster than React's.

https://github.com/infernojs/inferno

[bionicles]

Hi, How can we make a react-phosphor / react-jupyterlab type thing so we can embed JupyterLab in our React app and share state? Typescript noob but studying it now

[gnestor]

@saulshanabrook's response on Gitter:

One short answer: You can't. Not only is JupyterLab not built with React it doesn't have global state storage.

Longer answer: You could wrap JupyterLab in a React component, but you would have to manually link the state to any changes in JupyterLab's application. We have been transitioning some of JupyterLab to use React internally and if you are interested in solving this problem long term, we would love to have your help with that. If that is something you are interested in, I am happy to help get you started there.

Which parts of JupyterLab are you looking to control externally?

[bionicles]

@gnestor

1. We need to be able to control the location / dimensions of the lab, so it can fit inside a desired position on the app (Potentially options.hostId passed to jupyterlab can control this)

2. We need to pass maps of nodes / links / selections to jupyterlab kernel, so user can prototype graph algorithms quickly. When the kernel updates the graph, it could dispatch CRUD operations to the parent react component, and when the user updates graph data in the app, it could pass this data as a prop to the jupyterlab

like

then inside jupyterlab component we could just render the lab one time, and watch for changes to the graph data, and dispatch updates to react state

[gnestor]

This all sounds possible but I can't say for sure without seeing some example code.

We need to be able to control the location / dimensions of the lab, so it can fit inside a desired position on the app (Potentially options.hostId passed to jupyterlab can control this)

I'm not familiar with options.hostId but you can certainly put JupyterLab in an iframe and control the dimensions of that.

We need to pass maps of nodes / links / selections to jupyterlab kernel, so user can prototype graph algorithms quickly. When the kernel updates the graph, it could dispatch CRUD operations to the parent react component, and when the user updates graph data in the app, it could pass this data as a prop to the jupyterlab

You can create a labextension that hooks into kernels and respond to kernel events, messages, etc. and communicate with the parent React app from there.

[bionicles]

here's a repo where i've attempted to create a react app for jupyterlab

https://github.com/bionicles/lab-component

I added index.js of examples/app to a "useEffect" hook inside a boilerplate create-react-app

"yarn start" and it tries to work but cannot find a kernel server and has some bugs:
the jupyterlab stuff automatically fills the whole screen when we want it to just fill the parent div
Unexpected token < in JSON at position 0
TypeError: Cannot read property '0' of undefined

next I tried adding main.py also from examples/app -- but python main.py fails as there is no template.html

how do you make the main.py function play nice with react app instead of html template?

EDIT: added index.html and webpack.config.js however when python main.py launches index.html it seeks bundle.js, which does not exist because create-react-app has conflicting build settings

[jasongrout]

For reference, @bionicles created jupyterlab/jupyterlab#6380 to continue the conversation about embedding in React.

[blink1073]

@jasongrout recently brought up the point that by depending on React in @phosphor/widgets, we would have to bump the major version of our library when React has a major version bump. The TypeScript definitions for React have also been historically brittle. In JupyterLab, we have been forced to declare the types as a pinned dependency.

I think instead we should make it easier to use React with Phosphor.

• Add the RenderWidget
• Utilize the fact that jsx can now be declared per module in TypeScript
• Add a pass through for React renderers to the Phosphor vdom
• Add examples of using React in a Phosphor widget and vice versa.
• Investigate allowing React components to be used as the renderers for the core Phosphor widgets.