This issue will serve as a GNIP, and it's something we're working on. We鈥檙e looking to do the work to migrate the geonode front end away from Angular to ES6 and React. We鈥檙e planning to do the work on a fork and PR it into master geonode when it鈥檚 ready.
The goal will be to replace the current frontend Javascript and AngularJS code with modern ES6 and React components.
General Steps to Complete this GNIP
Our goal is to remove AngularJS as a dependency entirely, and get all of the Javascript up to date with modern ES6 syntax. We'll also be able to streamline the JS asset management in the process. If there are any questions I'll be happy to answer with what we're planning, and once we have a branch up and going I'll edit this post and include a link to the branch so the community can see the work in progress.
@afabiani @simod @capooti @olivierdalang can you kindly express your vote?
Looks a good plan... a bit afraid it could break some things, especially on contribs.
Nevertheless:
I would be very happy to see GeoNode cleaned from all those mixed stuff and technologies and have a clean and unique way to write frontend logic.
I would be very happy to cleanup obsolete contrib apps and, if possible, remove them from trunk and attach as external libraries instead, with the positive effect of cleaning up the settings too.
Hopefully this GNIP would be a good occasion to start the positive trend.
@Coop56 we (GeoSolutions) are working on the integration of several new components for the maps previews and views, based on our React based framework MapStore. It integrates charts widgets, a new timeline, a style editor, and several other features.
We're going to merge this client soon in January on master, but it's already working and deployed on some of our projects.
So we support the idea of migrating all the GeoNode's frontend from Angular. It is advisable to coordinate the offert, at least to agree on a toolchain (Webpack and Node versions, etc.) and, hopefully, on some basic componentes and patterns. (e.g. we adopt Redux, RxJS).
This would help a lot to obtain a seamless integration and provide a coherent structure to the frontend architecture.
@giohappy I'm starting work on the Webpack tooling this week - could you point me towards your setup so we can make sure they're in line please?
@Coop56 Any news on this? I really think this would be a very valuable PR. Let me know if you need help with something.
@t-book Yep the work is in progress.
@Coop56 Can you tell me which parts of the codebase currently have AngularJS/Angular as a dependency and also the motivation for moving to ReactJS instead?
The GeoNode 3 vision focuses on the next major version being Web UI framework agnostic. Will the work being done here make React the obvious choice for users?
Also, #1331 suggested several options for map interfaces that are implemented using Angular.
@isedwards
Also, #1331 suggested several options for map interfaces that are implemented using Angular.
This is outdated. The current development is moving to a react based viewer which might let a user switch between different mapping libraries.
@isedwards this GNIP has nothing related to the next version of GeoNode which is also going to be renamed GeoNode 4.
React is the natural choice currently because the most rich client built with modern technologies is MapStore 2 which is again react-based as @t-book already explained.
However nobody would limit developers to come up with a new external client angular-based or to improve Maploom which was the first developed with that library (I guess with an old version of Angular though)
This work has been put on hold by NGA currently. Working with them to identify who/when this work will start back up. Hopefully we will know more by the end of April / middle of May.
Most helpful comment
@isedwards this GNIP has nothing related to the next version of GeoNode which is also going to be renamed GeoNode 4.
React is the natural choice currently because the most rich client built with modern technologies is MapStore 2 which is again react-based as @t-book already explained.
However nobody would limit developers to come up with a new external client angular-based or to improve Maploom which was the first developed with that library (I guess with an old version of Angular though)