[RFC] web_react: React.js Widget

[lasley]

The intent of this module will be to provide a basic React implementation in Odoo.

I'm currently back and forth on whether one of the intents will also be to integrate with our existing Backbone.js model & router framework. I have played around with this a bit by hand now and have it working well, we won't be able to use some of the great performance tuning features like shouldComponentUpdate due to Backbone's mutative nature.

I did find a decent middle ground in react.backbone, but I still see the lacking performance features here too. It's definitely better than my by hand implementation, but it's still a pretty naive implementation IMO.

I'm wondering if integrating the Backbone framework would cause more harm than good though? The only application I know of that actually uses Backbone is pos, which I see no reason for using React in. We could instead use something like Redux, which I feel is more fluid when architecting for React.

In my head, I envision the React Component to be the same concept as the Odoo Widget. The actual React Component would be stored in a component attribute of the new widget, which would render and have lifecycle managed via overrides of the standard widget lifecycle management methods (renderElement, replaceElement, etc). We could even use our standard QWeb template handling via the pre-existing template attribute of the widget.

I'm sure I'm missing some of the high level here, but this is the plan for the most part. Basically just hook up React & provide a ReactWidget API for developers to use, which circumvents a lot of boilerplate. Any thoughts, or advice of pre-existing code to base from?

[pedrobaeza]

Do you know https://github.com/trobz/openerp-web-unleashed?

[lasley]

Interesting, I did not - thanks @pedrobaeza!

This looks to be exactly what I'm looking for! Too bad there's no licensing - I created trobz/openerp-web-unleashed#11 to find out & will report back.

[lasley]

Alright so looks like it's licensed under AGPL. Unfortunately that's a blocker for me, I need LGPL, so will need to create a competitor.

Do you have any experience with this library? It would be really nice to know shortcomings of it from experience in order to design around them.

[pedrobaeza]

I'm afraid not. I only know it as a global ecosystem observer, but I haven't done anything with it.

[lasley]

No worries- I'll play around with it a bit before I get started then 😄

[yajo]

What would be your goal with this?

[lasley]

I'm having trouble making any sort of complicated view outside of the Odoo frame when it involves a data model. The goal here will be to provide the ability to create a React component coupled with a data model, using the Odoo widget framework. I'm also thinking some basic widgets are in order, like a o2m.

The component would be included in a standard website template as would would any normal React component:

<MyReactComponent name="whatever" />

On second thought, this should probably be named website_react though. We're fine in web, my struggles are more website than anything. Specific use cases:

• Rework the vertical-medical website prescription checkout process. It's a giant form using website_field_autocomplete and some custom JS right now & is basically only semi-functional.
• Barcode interface - I need dynamic updating data due to quick scans causing some really fun issues when URI switching
• Delivery driver interface - basically a POS for delivery drivers, will require offline data

[lasley]

Actually now that I'm thinking about this in context of website, the React components wouldn't be widgets but would instead be snippet.animation. I need full controller routes in my use cases, but some components could be great in the website editor.

[pedrobaeza]

If you can wait a bit, @ged-odoo told us on Odoo days that they are preparing a big refactoring to decouple web widgets from web client architecture with one of the goals being to use them also on website. He was not sure if this is going to be ready on v11. Géry, maybe you can update us the status of this?

[ged-odoo]

well, we are indeed doing a huge refactoring of the odoo JS framework. Maybe some people will be interested in an update, and since we don't have an official odoo technical blog, I might as well give some info in this issue. If it is of interest to you, you can have a look at the current code in the master-web-views branch.

We are rewriting (almost) from scratch all the views. We take this opportunity to update our design principles to (more) modern approach. We have new JS coding guidelines, all our functions will be documented, all parameters and return values, we separate private and public methods, we share much more code between views, we have a complete control on how onchanges and external actions are done, so there will not be any flicker in the UI.

And something huge (to me): we have a brand new JS unit test framework that allows us to fully tests views (like instantiating a form view with a given arch field and some parameters, then interacting with it exactly like a 'real' form view).

This will allow us to use views (and field widgets) whenever we want, and in particular, on the website (we still need to make sure that we get the proper JS files).

Also, this will introduce a real separation of concern: the code responsible for fetching the data ('model') is properly separated from the rendering code, and from the controlling code.

I believe that this work will be complete soon (it may land in master the next month, or the one after).

Then, I have a few important items on my todo list:

• refactor the rest of the web client: view manager, action manager, web_client, session. These classes should be properly designed and fully tested
• rewrite the JS documentation on our website: right now, it is almost criminally out of date. I will give an internal training on odoo JS, this will give me a better idea on what is needed, and will give me the time to prepare some material. I also have a few pages of design notes, that I could use as a nice baseline for a documentation that will actually be helpful. Also, add some documents to explain our design principles, how to interact with widgets, with views, with fields, ...
• improve our internal process (introduce a checklist for commits in JS, make sure our reviews are useful, make sure our testing process is working, ...)
• finally do all the tasks in our pipeline that are blocked on the new JS framework. We will be able to keep evolving our web client, but with much more safety than before.
• someday: rewrite/professionalize the website code (it should use the same principles as the rest of the web client)

All together, it means that we will have rewritten the web client in one year, and it will be awesome. I am really excited about this. Also, I believe that once this is done, the JS code will be so much more stable, API wise, so it will be less risky for everyone to write large modules in JS.

Now, for the web_react idea, it depends on the scope of your project. If you want to use react in a widget, you can go for it now, this looks (mostly) independent. If you want to integrate more deeply with the odoo internals, it may be wise to wait a little bit. Also, note that I am personally interested in React, and that our new views/widgets should be much closer to a react component. The new widgets don't store state in the DOM, don't reference their parents, and have a much clearer separation between their 'state', their 'props' and their rendering process.

[pedrobaeza]

Thank you very much for the update, Géry. I'm also excited to have this soon!

[simahawk]

@ged-odoo thanks for the update! @lasley I'd wait for this :)

Meanwhile, if your main issue is to easily build front-end forms you could have a look at OCA/website-cms#9. My plan is to add a minimal support for onchanges & co. so that you won't have to plug custom JS everytime.

Right now it works w/ every model and every field. Widgets are still a WIP tough -especially o2m and binary - but I plan to add new widgets for image, multi-attachment upload, sub-records creation (x2x fields), etc. Last but not least, I want to add validation on the fly and make all forms work via ajax submit on demand.

[lasley]

Wow @ged-odoo this is possibly some of the best news I've gotten in a long time, thank you for providing it to us!

After looking at the code in master-web-view, I agree that it is a good idea to hold off here. These views are way more modular - I'm loving the new abstract classes!

Géry was not joking - I think this new architecture may cover my requirements fairly well. I'm going to play around in this code more so I can form some more intelligible thoughts on it, and will update this RFC description with the new plan (or close it if everything I need is now possible).

@simahawk - Ok yeah so your way is probably best for the moment. I'll probably have to diverge on the delivery POS, but that is kind of an outlier project in terms of specs anyways - was just worth a shot trying to group it in. I'll follow-up in the PR on that.