I am Aditya Todkar a second year undergraduate I went through the project ideas of GSOC 2017.
Greetings, @aditodkar! Thanks for expressing interest in GSoC with Plone. We'd love to have your help in making the Patterns-based Widgets in Plone better. I encourage to to begin by reading this post to get yourself started learning about Plone. There are certainly issues in the linked list of beginner-friendly issues that you could work on given your skills.
Again, welcome to Plone. We are glad you're here.
One step in improving our widgets is to start integrating and converting patterns over to using ReactJS.
For example, here is a branch where some of the work is started: https://github.com/plone/mockup/tree/react-upgrade
So far, this branch upgrades react to a newer version and converts the querystring pattern to use react.
Moving widgets to React is a fantastic GSoC project idea! We (kitconcept) created a React-based search for collective.solr here:
Maybe this can be a starting point (together with the link that @vangheem provided) .
@aditodkar, I'll let @vangheem and @tisto chime in with what they want or expect, but from the perspective of the GSoC program manager, what we all want is a successful, completed project. Your interest and investment in the code you write is an important part of getting that successful, completed project. So from my end, I think you should write a proposal that you will be excited to implement.
@aditodkar The huge advantage of using React is that we have tons of state-of-the-art widgets ready to use. Therefore it might be a lot easier to just look for React-based replacements of the existing widgets than to improve them.
Either route is a reasonable project, but probably not both, unless you are wrapping existing (easy win) existing ReactJS components/widgets at the end of such a project.
The reason I suggested new widgets in the original idea list (both last year and this year) for Plone (vs rewriting anything) is that there are easier wins to be had: rewriting incumbent functionality involves pleasing its existing user base (or 80%+ parity with existing functionality for each widget). Writing new widgets has no such incumbent pressure.
OTOH, if the community is very set on make-everything-React-based (not unreasonable, I just don't have the gauge of this), writing new widgets just creates more future porting work for the community. <-- @vangheem @thet @tisto thoughts on this?
@seanupton my personal opinion is that we should move entirely to React/Angular2 widgets in the future. This is what I already did for collective.solr and this is what Wildcard did for castle CMS if I am not mistaken.
Whenever I need a new widget in Plone, I will rewrite the component in either in React or Angular2. This might allow us to share widgets between existing Plone versions (Plone 5.x, 6.x) and more modern front ends on top of plone.restapi in the future. We can do that today with requireJS, but I hope we can get rid of that in the future as well...
The web changed significantly in recent years and we need to attract new developers. If I would tell one of my front-end devs to use jquery-based widgets, that send HTML back and forth, they would think I'm on drugs.
plone.restapi + existing modern widget libraries are the future. The sooner we realize that the better for the Plone community.
Also big +1 for plone.restapi in Plone core.