Upgrade to Rails 6.0

[jvendetti]

https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-5-2-to-rails-6-0

[syphax-bouazzouni]

Any news about this ?

This may help you https://railsdiff.org/5.2.6/6.0.0, it's gives you all the changes to do to go from one version of RAILS to another.

Also, in my opinion we should directly go to Rails 7 because the main reason (for me) to upgrade to Rails 6 was webpack (to use modern JS), but with Rails 7 webpack is no more used.

More details, here :

• https://github.com/rails/webpacker
• https://world.hey.com/dhh/rails-7-will-have-three-great-answers-to-javascript-in-2021-8d68191b

[jvendetti]

The application is running on Rails 6 in my local dev environment. I had to pause this work before finishing and publishing to production. I've been asked to look at some other issues that were deemed higher priority.

I'm aware of the new developments surrounding the handling of JS in Rails 7, and have read DHH's article that you linked above. I'll probably put the 6.x upgrade into production without Webpacker integration, then look at getting onto Rails 7 as soon as possible so that we can start taking advantage of JS Bundling. I haven't had a chance to think about whether the Hotwire defaults in Rails 7 would make sense for us.

[syphax-bouazzouni]

I think that some of the Hotwire defaults could be useful for us, for exemple :

• Turbo Frames for transforming the UI to an SPA-Like app, where it allow us for predefined parts of a page to be updated on request by AJAX
• Turbo Streams can be also be useful for us in modules like the notes (using web sockets)

However I'm not at all convinced by the Stimulus JS framework, for the front i think in the mid-term we should purge gradually JQuery and transform it to vanilla web-components and use a lightweight front-end framework for more complex components, like preact.

For the JS bundling in Rails 7, i think we should use esbuild instead of webpack, it's much less complex and it is 40 times faster (see https://esbuild.github.io/). And esbuild come by default with typescript and JSX.

So this was my thoughts of how we should develop the ontoportal UI in the future. I will try to apply it in my next contributions and i'm really interested to know if you thought about it and discuss about it, so that we could all (ontoportal alliance) agree in the techs to use.

[jvendetti]

Hi @syphax-bouazzouni.

• I agree with your points about Hotwire
• I agree that we should reduce/eliminate our dependencies on JQuery wherever feasible
• I agree that we should use esbuild in Rails 7
• I haven't had time to look at preact

Yesterday I merged some code into the master branch that upgrades the application to Rails 6.0.4.1. I thought it was production-ready, but noticed after I did a deployment that the Mappings and Notes tabs for all ontologies were taking anywhere from 2 to 4 minutes to render. The performance was so bad that I had to redeploy the v6.6.0 tag in production. I'm currently trying to diagnose the issue in our staging environment. However, if it ends up taking more than a few days, we're looking at having to revert those commits.

[syphax-bouazzouni]

Hi @jvendetti,

Thank you very much for taking the time to respond to my messages, and for your work in upgrading to Rails 6. (i will deploy it in our test environment, to see if we have the same issues and help to fix it if it's needed).

And speaking about the points that I wrote in my latest comment, with time and more reflection after digging deeper in the Stimulus JS framework, I changed somehow my opinions about it.

So below I listed my latest proposals about the UI technical enhancements to do :

• Go directly to Rails 7 with esbuild as our front bundler (we agreed on that)
• Use where we can Hotwire, to make our app more reactive and lucking more like a modern single-page application app. (here is a good reference to learn it: https://www.hotrails.dev/)
• Replace all our jquery (if possible) with [Stimulus JS](https://stimulus.hotwired.dev/), which is aimed and built to be its replacement. It will not have any major performance or visual effect in our app but will make our js code more organized following one and a unique pattern, the framework one. Currently, our js codebase is a lot of files with hundreders of functions and classes each one written in its own way, making it really difficult to understand and know what it does and where it does it.
• For preact (or any other js framework that does client-side rendering), with more reflection and research I found that it is not really the philosophy that the RAILS framework wants us to follow. They want us to do the much server rendering as possible. So in my opinion With the stack rails-hotwire-stimulusjs we should be compliant for almost all our UI needs, preact will still be useful only if we need to build some complex-reusable UI component.

So that was my (modest) opinion about the roadmap that we should follow in the technical part. In the functional part, we are currently discussing at Agroportal to do our mid-term roadmap, listing and prioritizing our most important features, to correct, improve, or/and to add to the portal. And we would be really interested to also hear from you (NCBO or anyone that is reading this) your thoughts about it, on what you are planning to do? what are the new features that you are working on? what do you want to implement but don't have actually the time/resource to (and in which we can collaborate on it)? What are your priorities?

PS: sorry for the long text, hope it's useful PS 2: I can extract my last section (the roadmap one) to a separate issue here, with its own thread. PS 3: Have a good day.