Final Report - GSOC 2023

My GSOC internship with the Wiki Education Dashboard is coming to a close. As a result, I am writing this report to go over my experience with the program!

This also serves as a follow up to my post from last month: Halfway Through GSOC

If you’d like to go straight to my list of contributions, please click here

Table of contents

Introduction

If you haven’t read my last post, here is a quick summary of the dashboard, taken from the project’s Github repo

The Wiki Education Dashboard is a web application that supports Wikipedia education assignments, edit-a-thons, and other editing projects. It provides data and course management features for groups of editors — instructors, students, and others — who are working on Wikipedia, Wikidata, and other Wikimedia wikis.

My project’s main goals were to refactor all the React components in the codebase into functional components and upgrade from React 17 to React 18. I ended up working on adding a new feature to the dashboard as well. (I will get into this later on)

Component Refactor Results

There are a total of 162 React components that needed refactoring. In my last post, I mentioned that I’ve refactored 46 components. That number has now gone up to a total of 71 components refactored (almost half!)

As you can tell, I did not manage to refactor every single component. However, I am still very happy with the quantity of components that I’ve refactored. I think this refactor has greatly improved code readability and scalability for a large part of the React codebase. Future developers of the dashboard will certainly benefit from working with the more modern tools available inside of functional components.

I also created this GitHub issue to track all the components that have not been refactored yet. This should serve as a good resource for other dashboard developers to pick up where I left off.

The aftermath of the React 18 upgrade

As mentioned in my previous post. I managed to succesfully upgrade from React 17 to React 18 with minimal issues. There aren’t that many new features that came out to be instantly useful from this upgrade. However, there are a lot of small optimization that were made that have definitely helped performance. Things such as automatic batching make state re-renders less frequent and more reliable. Here’s a snippet from the official React 18 upgrade guide that talks about this feature:

Starting in React 18 with createRoot, all updates will be automatically batched, no matter where they originate from. This means that updates inside of timeouts, promises, native event handlers or any other event will batch the same way as updates inside of React events

Another useful addition is the strict mode changes. Here’s another snippet from the React 18 upgrade guide that talks about the changes:

React 18 introduces a new development-only check to Strict Mode. This new check will automatically unmount and remount every component, whenever a component mounts for the first time, restoring the previous state on the second mount.

The dashboard codebase does not use strict mode currently. However, there are plans to implement it at some point. So in the future, this will be great for debugging.

Improving the ticket system search

After spending most of the internship working on component refactors, I decided to switch things up and work on something new. That’s when I found this GitHub issue related to improving the ticket system search functionality.

As a quick rundown, the dashboard has a tickets system where users can send tickets in to staff/instructors. These submitted tickets can then be searched for using the tickets view. At the time this issue was posted, users were only able to search with one search type at a time (email/username, content, subject or course slug)

What this issue asks for is to add the ability to search for tickets using multiple search types simultaneously. This required touching on both the frontend and the backend parts of the codebase.

The frontend had to be changed to add more input fields for the user. There needed to be 4 input fields so that users can search for all 4 search types at once.

The backend had to be changed to actually implement the queries needed that enable multi-search functionality. Instead of querying just one ticket attribute based on the inputted text, we now had to query up to 4 attributes based on how many search types are being used.

Here’s what the tickets dashboard looked like before the changes were made:

Here’s what it looks like after:

This was the first real time I had to really dig into the ruby on rails code to add some new functionality. So it was a great learning experience for me.

Conclusion

Google Summer of Code has been such a great experience for me. Being able to improve both the developer and user experience of the dashboard, then having other users benefit from the improvements I’ve made is such a great feeling. I also think that I’ve learned so many new skills and refined old ones while going throught this intership!

GSOC has also convinced me to start being an active open-source developer. I will continue contributing to the dashboard even after GSOC ends!

List of contributions

Here’s a table showing all of the contributions I made to the Wiki Education Dashboard up to this point: