React binding for OnsenUI is impossible

[c58]

Hi!
In my recent researches i've tried to run OnsenUI with React. And my conclusion – it is impossible to use OnsenUI with React (with all benefits) because of OnsenUI DOM mutations in web components. React just brakes onsen web components on re-render if it uses custom inner template to show the content (ons-page, for example). I have discussed the issue in Preact repo there and @developid made an example of the problem

There is no solution to make React reuse WebComponent's inner html structure. So, there is no way to make a "binding" like Angular one... But we can rewrite web components with React.Component. There is my work on it: https://github.com/c58/onsenui-react
Many of core components already ported and improved. I have done this in two days. So, the complete port is not being very long journey.

I think it may be better to implement core with React like components and then write Angular binding on it. The library still might be slim and self contained if we include small react-replacement library, like Preact, with a bundle. We might use Preact if React is not available (just like Angular uses jqLite when jQuery is not available).

What do you think about it?

[philolo1]

@c58 Thanks for your input and your work / thoughts. I am actually the one in our team who currently works on the react bindings. You are right, that every time that the dom changes, react needs to be informed. We want our framework to be as agnostic as possible, so if we would implement everything in pure react component, people would not be able to just use pure javascript. You don't need to rewrite every component, but only write special component for those who change the dom, for example the navigator. So what we esentially want to do is write a component OnsNavigator for example that uses ons-navigator internally and ones the dom changes our component gets informed. You can take a look at my repo its still in an early stage, but here it is : https://github.com/philolo1/OnsenUI/tree/my_nav_2, and here is the OnsNavigator https://github.com/philolo1/OnsenUI/blob/my_nav_2/bindings/react/components/OnsNavigator.jsx, and examples: https://github.com/philolo1/OnsenUI/tree/my_nav_2/examples/react.

[c58]

@philolo1 interesting. I agree, that simple components without any logic (ons-button, etc) does not need to be reimplemented. React works well with class and style attributes mutated directly. But time needed to reimplement this component is very small. Much more time needed to implement harder components, like "ons-splitter" or "ons-carousel". I have looked at your work and it is not seems to work in "react way". A lot of React.render and dom mutation is not a good idea with React.

Also i think that OnsNavigator is useless in a big react application. My navigator implementation is a special RouterContext for react-router. It makes possible to describe a whole application structure in a declarative way, and navigate just with a general links:

<Router history={browserHistory} render={props => <OnsNavigatorContext {...props}/>}>
    <Route path="/" component={PageA} flat>
        <Route path="/test" component={PageB} />
        <Route path="/another" component={PageB} />
    </Route>
</Router>

It is very cool feature, in my opinion.

We want our framework to be as agnostic as possible, so if we would implement everything in pure react component, people would not be able to just use pure javascript.

I understand it. As i said, React may be replaced with Preact and packed to a bundle. Over a Preact components might be implemented WebComponent binding, that is easier to implement, then React binding for WebComponents.

To conclude. A "react binding" may be called so only if developer can achieve all benefits of both worlds – React and OnsenUI. In my opinion, there is no way to do that with WebComponents as a core, because any "react binded" component is just a hacky hack. If core implemented with React, there is still a problem to make a binding for Angular. I think there is a place for two (or three) libraries, based on same CSS Framework and some little codebase (fastclick, animation, back button, gestures), but with very different components implementation.

[philolo1]

Thanks for your feedback. @argelius might also comment here, if he feels like it :). The component does not work the react way, but it does not really matter for the user, since he can use all the components he writes himself the react way! Concerning performance, react is basically calling render when the webcomponent is changing the dom, so we basically do the DOM manipulations twice, that is a slowdown but not significant in my opinion, unless you do a lot of dom manipulations. Ideally we will write some interface in the webcomponent that tell react to do those manipulation and let the web component do nothing at all, but that is even more tricky. Btw i have been following this article : https://github.com/ryanflorence/react-training/blob/gh-pages/lessons/05-wrapping-dom-libs.md. I think it will be quite unlikely that we can go your way of writing the core both in angular and react, but lets keep this discussion open and hear other opinions as well!

[philolo1]

Closing this issue now, since we have now an extension that is working (with probably some bugs and some components missing): https://github.com/OnsenUI/react-onsenui