1

If Cycle uses virtual dom and so does React, then why can I not use React Components inside a Cycle.js app?

Would it be possible to use wrap existing React Components into Cycle.js components ?

This question relates to : Higher order FRP with React - why is it not happening?

Community
  • 1
  • 1
jhegedus
  • 20,244
  • 16
  • 99
  • 167
  • 1
    I'm not quite sure why you are asking that here, rather than on the cycle issue tracker. This question has a very high "can only be answered with opinions" factor so feels pretty off-topic. The obvious question is "is your claim actually true". Do they use the exact same virtual dom (there are many) with exactly the same APIs and programming model (again, there are many)? If they don't, you have your answer. – Mike 'Pomax' Kamermans Dec 20 '16 at 17:11
  • Right, but why are they not using the same VDOM ? Would it make sense to use Cycle.js with React at all - I suspect maybe not ? If not, why not ? Why is Cycle.js not compatible with React ? Only because it uses a different VDOM ? Or is there some other reason too ? Maybe even if it would use the same VDOM it still not make sense to use React and Cycle.js together, if that is the case I wonder why not? Why not reuse existing React components in Cycle.js ? Would it be a too much price to pay (in terms of wrapping complexity) for not too much benefit (reusability of existing React Components) ? – jhegedus Dec 20 '16 at 17:38
  • "virtual dom" is just a concept, and you can implement that concept in a million ways, tailored specifically for what the code needs are. A much better question would be "why would they use the exact same virtual dom datastructure and API? do they do exactly the same thing?", rather than thinking about it the other way around. If they don't do the same thing, then using the same virtual dom implementation is inefficient (either due to lack of dedicated API calls, or bloat from functionality that isn't needed) – Mike 'Pomax' Kamermans Dec 20 '16 at 17:42
  • Interesting point! – jhegedus Dec 20 '16 at 19:15
  • 1
    To answer a question raised in this comment thread, React is one of the worst virtual DOM libraries out there to be used as a UI layer in a framework. Note, as a library itself it is great because of its community support. But, as a layer in a framework, it's not even close to the best virtual DOMs, in performance and size. There are multiple other virtual DOM libraries, to name a few: Inferno, snabbdom, virtual-dom, Bobril, etc, faster and smaller than React. Also, React has its own event delegation system, which in Cycle.js would be entirely bypassed. We handle events differently. – André Staltz Dec 21 '16 at 10:49

2 Answers2

2

Because React's support for Web Components is lacking. See https://github.com/facebook/react/issues/7901 and http://staltz.com/react-could-love-web-components.html

It is technically possible to build React support in Cycle.js, but then you may also start asking whether other frameworks like Ember or Angular or Aurelia should start doing the same out of the box. Then, the question could be expanded even further by asking Aurelia components to be supported in Ember. So building support for "Foo" components in "Bar" framework is counter-productive. Web Components are the sane way to handle this.

André Staltz
  • 13,304
  • 9
  • 48
  • 58
2

Cycle.js is generic enough to be used along other frameworks/libraries. In fact there's redux-cycle-middleware which allows you to use React/Redux along with Cycle.js. With this middleware you wouldn't be using Cycle to handle DOM side-effects; instead you'd use React. Then when you need to handle other side-effects (HTTP, WebSockets, anything that isn't DOM...) you can use Cycle.js.

Luca Matteis
  • 29,161
  • 19
  • 114
  • 169