Page MenuHomePhabricator

Proposal - Modernize JavaScript build process and dependencies for Wiki Education Dashboard
Closed, ResolvedPublic

Description

Profile Information

Name: Shashwat Khanna
Github: TheTrio
Location: India
Time Zone: IST (UTC+5.30)
Working hours: 3:00 PM to 3:00 AM (IST)

Synopsis

Wiki Education Dashboard (the Rails app that powers Programs & Events Dashboard) is a complex web app for keeping track of contributions to Wikimedia projects. It's widely used by the global Wikimedia community for edit-a-thons, classroom wiki writing assignments, and a variety of other initiatives.

This project aims to look for areas of improvement in the javascript side of the dashboard. A major part of this would be replacing older dependencies that are no longer maintained with newer ones, reducing the bundle size, while also making the codebase in line with the rest of the JS ecosystem. This project will also involve rewriting some of the legacy code in a more modern way, making it more approachable to a wider audience of developers and contributors.

Possible Mentor(s)

Sage Ross

Have you contacted your mentors already?

Yes

Deliverables

Phase 1 Evaluation

  • Upgrading to webpack v5
  • Update all webpack plugins
  • Replace unmaintained plugins with a suitable alternative
  • Convert server-rendered lists to react components
  • Convert the remaining ajax requests to fetch
  • Replacing react motion with react spring
  • Remove UNSAFE life cycle events from the React components

Final Evaluation

  • Rewriting the survey files to use vanilla JS instead of jquery
  • Moving away from moment js - possibly to date fns
  • Reduce usage of createReactClass
  • Document the conversion from class-based to functional components to help future contributors

Timeline

Community bonding period

During this period, I will inspect the project and plan out my changes.

I will start by reading and studying about the various changes I propose, and how to best implement them. For example, for webpack, I will look into the following:

  • Plugins and loaders which are no longer being maintained
  • Modern alternatives to such plugins/loaders
  • Plugins that can be eliminated because of improvements in webpack

I have some ideas about these already(more details below) - but I will spend this time finalizing everything.

1. 13 June - 19 June

Do the initial setup for the upgrade to webpack 5. As much as possible, I will try to delay plugin updates. Instead, I'll be focusing on the webpack configuration itself. Since webpack 5 removes all deprecated features, several config options will need to be changed.

Another change I might have to make is removing “parallel webpack”. The repository for this package has now been archived and from the looks of it, it doesn’t support webpack 5 (although it is listed as a peer dependency). Webpack has gotten much better over the years and the use of this package might no longer be necessary(if it's even possible)

2. 20 June - 26 June

During this period, I will try to update the plugins to their latest versions. Two plugins that I have identified are css-loader and eslint-webpack. The upgrade path for these plugins looks relatively straightforward - and therefore I will update them first

I will also try to identify and remove plugins/loaders which are no longer being maintained. One such plugin is the html-webpack-exclude-assets-plugin, which hasn’t been updated for 4 years, with the latest version still being 0.0.7. I will attempt to find more modern, well-maintained alternatives for these plugins.

3. 27 June - 3 July

I mostly intend to use this period to look for optimizations that might be possible. One possible improvement would be using modern webpack features like Asset Modules, which will eliminate the need for additional loaders such as url-loader. url-loader should work on webpack 5, but it has been deprecated.

I will also attempt to fix and debug any issues that might have been pending.

4. 4 July - 10 July

Replace react motion with React spring. I will also remove the use of the UNSAFE component lifecycle methods in React. They have been deprecated and react will warn you if you use them.

5. 11 July - 25 July

During this period, my main goal would be to reduce the use of jquery in the app.

I will begin by rewriting all AJAX requests to use the fetch API instead. I already have a PR that did the bulk of the work but some AJAX calls are yet to be converted. For example, JSONP requests are still being made by jQuery since fetch doesn’t support it natively.

I will also start converting the various server-rendered lists to react components. These used to use jQuery(in app/assets/javascripts/utils/course.js) to sort but now use vanilla JS. Even then, converting them to react components would help simplify the code.

The biggest of these server-rendered lists is app/views/campaigns/_course_row.html.haml, which is what I’ll start with and then move on to others.

6. 25 July - 29 July

Phase 1 evaluation. I will continue to submit code and make patches based on the feedback I receive.

7. 30 July - 10 August

Moment JS is a library we use to parse and manipulate dates in the project. However, as the docs for Moment JS note, it has much better modern alternatives. Keeping this in mind, I aim to convert the date parsing logic to use a different library.

Unfortunately, we currently have a dependency that depends on moment js - moment-recur. This plugin will have to be replaced with a suitable alternative.

Also, we have another date parsing library - date-fns installed, as it's a dependency of chartkick. This means it's probably a good idea to replace moment with date-fns. The moment recur plugin is only used in a handful of places so it shouldn’t be too difficult to implement the functionality we need from it ourselves(if we can’t find an alternative)

8. 11 August - 25 August

The survey system deployed by the app serves static HTML. The dashboard currently uses jQuery to manipulate the html. While I hope to convert it to a react component, doing so would require abandoning the current system since it doesn’t look like RapidFire is going to support an API for taking surveys anytime soon. In all likelihood, I will work on converting it to vanilla Javascript instead, further reducing the amount of jquery in the codebase.

9. 25 August - 12 September

Currently, over 130 React components in the app are created using createReactClass. This is a legacy API. The React community has moved on to using functional components and ES6 based class components. Some third-party packages we use(like React Router) now only support the use of hooks. Using class-based components with them needs a wrapper functional component and even then, it's not perfect.

Keeping this in mind, I will convert some of the more complicated components to functional ones. Since there are so many of them, it might not be possible to get rid of createReactClass as a dependency altogether, but I hope that the changes increase the quality of the codebase.As for the modern class-based components, I don’t think there’s any need to rewrite them - at least not presently. The React docs say it's perfectly fine to have both kinds of components in an application.

Most of the changes would be related to third-party packages, like Redux, for which we use the connect API presently. While this API can also be used with functional components, the Redux docs suggest using hooks, which greatly simplifies the code. The life cycle methods would also need to be replaced with the useEffect hook.

While making these changes, I’ll also make sure to document the general procedure to guide others who are new to the project to convert the components themselves.

Participation

I will be available on both Slack and email. I am on the WikiEduDashboard slack channel and have been in contact with Sage Ross for some time now. I will use Github to collaborate, submit and work on code. I have used GitHub for a while now and believe that I am accustomed to its workflow.

About Me

Education (In Progress)

College: Indian Institute of Information Technology(IIIT), Pune
Year of Study: 2nd year
Field of Study: Computer Science Engineering

How did you hear about this program?

I have been into programming for a long time. I mostly created projects which were useful to me. Working with others on a project excited me, but I mostly collaborated with my friends. After getting into college I came to know about Google Summer of Code from my seniors. One of my friends got selected for GSOC last year, and after talking with him, I looked at the program with greater interest.

Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program?

My current semester completes by the end of April. Following this, I have a summer break for about 3 months. Up until August, therefore, I will not have any classes and I would easily be able to give this project my entire focus. When my college commences, I will be able to give 3 hours on weekdays, and 5-6 on weekends, giving me about 25 hours per week. This is a fairly conservative estimate and I will probably be able to give more time to the project.

In either case, I shouldn’t have any exams during this period, and I think I have planned my timeline in a way that gives me the chance to do the major stuff I have in mind before my college reopens.

We advise all candidates eligible for Google Summer of Code and Outreachy to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?

I only plan on applying to Google Summer of Code with Wikimedia Foundation.

What does making this project happen mean to you?

As I’ve already mentioned previously, programming has always fascinated me. In the past couple of years, I’ve tried multiple times to work on projects other than my own, and while I have worked with a couple, they have been relatively simple - be it changing a couple of lines of JS or CSS. I of course still learnt a lot from them and met amazing people along the way.

Working on something at the scale of the dashboard would be something else entirely. While my proposal might not make much of a user-facing change, I believe that it would undoubtedly help future contributors be a lot more familiar with the technology used by the dashboard. This would inevitably lead to a positive outcome not only for the developers that work on the codebase but for all the users who use the dashboard.

And finally, it would fulfill my long desire of contributing to an application used by people all around the world. Ever since I came to know about open-source software, I’ve always been awed by the people who contribute their time and effort into projects simply to make the lives of others easier. Having used so many amazing applications built by people in their spare time, I wish to give something back, however little it might be :-)

Past Experience

Contributions to Wiki Education Dashboard

I have contributed to the Wiki Education Dashboard for over a month now. My contributions can be found here

Some of my major contributions are

Pull RequestTitleRelevant Issue
#4869Update react router to v6#4604
#4886Switch to Media Wiki API for fetching recently edited articles#4392
#4818Convert ajax to fetch#4684
Past projects

I have worked on a lot of personal projects and they have helped me learn a number of skills. It wasn’t until recently however that I started taking an interest in Web development, and I will describe a couple of my projects

Dear Diary

This was my first full-stack web application. I created it mainly because I couldn't find a good free alternative to write my diary entries on. It is written (as you might expect) using vanilla JS for the front end, and node for the backend. Because of this, I think I have a good understanding of how Javascript works and can work around so many of its quirks. It was also here where I learned stuff like docker, authentication, using a shell, etc.

Slick Chat

This was my first major React project. It was a basic chat client, allowing users to generate chat rooms, where they could invite and talk with their friends. This project dealt with a variety of technologies that were new to me, including WebSockets, routing, state management, and SQL databases. It is here where I discovered a lot of the stuff which is useful for this project - given that it's also built with React.

Coding Skills
  • Proficient in Java, Javascript, and Python. Moderately comfortable in C/C++ (which I use primarily for college)
  • Have written a lot of vanilla CSS
  • Reasonably experienced in React
  • Have worked with Node alongside Express for the backend.
  • Have used Linux for a couple of years now and am pretty comfortable with it
  • Used git for version control.

Ruby is something that I looked at very recently after coming across this project and I believe I can navigate and understand the codebase. Although writing ruby is still a challenge for me, it is something on which I have been working.

Other open-source projects I’ve worked on

The main project that I have contributed to is PrettierLichess. It is an extension for Chrome/Firefox, which tries to give the lichess website a more modern look. The project is primarily CSS and it is because of this project that I enjoy using CSS so much.

My contributions have mostly been fixing small CSS issues. They are:-

Pull RequestTitleRelevant Issue
PR #87Fix overflow on large screen sizes#85
PR #67added styles on hover#66
PR #52centered game board in puzzle racer#51
PR #47Fixed api docs styling#38
PR #46Fixes background of rating range input
PR #44centered chess board in Puzzle Storm#43

I also have contributed to LeetCode rating predictor with #6 but I haven’t had the time to dive more into the project.

Event Timeline

Hi! I am Srishti, one of the org admins - it's great to see your interest in applying to GSoC with Wikimedia! You can safely ignore this message if you have already followed our participants' guide. As you develop your proposal, we want to ensure that you follow the application process steps: https://www.mediawiki.org/wiki/Google_Summer_of_Code/Participants#Application_process_steps, primarily communicate with project mentors, integrate their feedback in your proposal, adhere to the guidelines around proposal submission, contribute to microtasks, etc. Let us know if there are any questions!

As the GSoC deadline is soon approaching in less than 24 hours (April 19, 2022, 18:00 UTC), please ensure that the information in your proposal on Phabricator is complete and you have already submitted it on the Google's program website in the recommended format. When you have done so, please move your proposal here on the Phabricator workboard https://phabricator.wikimedia.org/project/board/5716/ from "Proposals in Progress" to the "Proposals Submitted' column by simply dragging it. Let us know if you have any questions.

My final report can be accessed here.

One of the major things that I couldn't do was rewriting the Survey route to eliminate jQuery. After discussing with @Ragesoss, I realized that this might be too large to complete in one GSoC internship. The best way to tackle this probably is to first add support for JSON in RapidFire and then use that to write a front end in React.

Apart from that, I was able to do (mostly) everything else. I also ended up doing a lot more in the tooling side of the dashboard - be it HMR, Testing coverage or the in memory dev server.

I've completed the GSoC evaluation and have submitted the work link there as well. If there's anything else that I need to do here, do tell. Thanks!