On spaghetti data structures and how React changed the way i think about them

I got started with ReactJS a few months ago, and I'm Lovin' It. From the get-go, you have to think in terms of components and one-way data flow. It makes it a little less convenient for "just hacking around" and making something, but that's OK; i'm using it for a big project.

In React, data flow is single-direction, from parent components to children. And if you're using Redux, there's a single state object that is the source of all data. In a diagram, it looks like this:

My previous big project (logletlab.com) does not use React. You have various components storing their local state in various ways, mainly <input> value, selected radio button, and jQuery data. The data flow looks kind of like this:

It's awful!

You have certain options that are only available when other options are selected. There's one spot where there are two places to do the exact same thing, so the elements have to mirror each other.

When i began the project, it wasn't so complex. I thought a simple HTML <form> with a bit of JS magic would be enough. (I also didn't know better.) But as the project grew, the requirements became more complex, and i just kept patching the code.

A few months ago i had to build a system to save and load the state. (This was still before learning React.) At that point i was able to basically just serialize the form to JSON and then load those values. Last week there was an urgent bug that some options weren't being saved (hadn't been needed till now). The problem is, some of these options are lists of text inputs. Others are radio buttons. Others are lists of checkboxes. Still others are plain text inputs or checkboxes. I patched the system (again) to save the rest of the options, but it's not clean at all.

I just talked about saving and rehydrating the state, but it's even more of a pain to actually use those options. The webpage is just a frontend for sending data to the backend, but it still has to pick which <input>s to send.

It would be much nicer everywhere if it could just have a single object that's the source of truth for the webpage. If i have the time, i'll do exactly that. I probably won't actually use React for this, but i will use the lessons it taught me.

Thoughts on Google Code-In 2015

For the uninitiated, Google Code-In is a yearly competition held by Google for highschool students, where the kids work with several open-source organizations. The organizations give tasks for the students to do, and also mentor them. Top performers (grand prize winners) earn a free trip to Google Headquarters in California. Wikimedia is the company behind Wikipedia, and MediaWiki is the software they use/create.

Well, maybe a computer showing Wikipedia could
also hold up the whiteboard

Another year of Google Code-In comes to a close. This is my fourth and final year participating in the competition, as i am now a highschool senior. This year i decided to work nearly exclusively with Wikimedia during the Google Code-In. I did a couple tasks with them last year too, and in fact, i still get a kick out of seeing the legend box on Wikipedia’s recent changes (last year’s task). I chose Wikimedia because i often use their services, and appreciated the chance to give back. And, of course, there’s some appeal to writing code that gets used on the 7th most visited website in the world…

One of the draws of Google Code-In for me is the chance to work with technology i normally wouldn’t. It’s a very different experience working within a large, established codebase and community than writing a library or program from scratch. There’s a learning curve, including reading and following long (and very specific) style guides. It seemed a bit ridiculous when i got an automatic failure for having a comment indented to where it made sense to a human reader, but didn’t strictly follow the guide. Style issues notwithstanding, I appreciated the opportunity to work with programs such as Kiwix, Twinkle, various MediaWiki extensions, and of course, the core itself.

During the course of the Code-In, i received some reminders of the fact that open source projects often have many differing opinions among its contributors. There was one task i looked at, but decided against taking it because of the discussion on Phabricator (MediaWiki’s bug tracker). It went something like this:

A: I think we should do this. B: I think we shouldn’t. A: I’m putting it up for GCI.

Since there was clearly some opposition to making the change, i opted not to get involved here, especially as i had no real opinion on it.

I did one task to add support for the lc: and uc: magic words to mw.jqueryMsg, a utility for parsing messages on the client side. My mentor gave me a “+2 Nothing I could complain about :)” and merged the code. A day later, i see a comment: “What about Turkish?” I completely didn’t think about other languages, and i was actually glad to see someone point that out. Luckily my mentor, Bartosz Dziewoński (whose help i appreciated but whose name i cannot pronounce), saved me by pointing out that the PHP implementation doesn’t support Turkish either, so it’s not a showstopper that my JS code doesn’t.

I didn’t feel a need to venture into IRC very often, but i did occasionally stop in to ask for some help, and was pleased to find people willing to assist. I once needed help setting a stylesheet to apply only when showing the printable version of the page. I asked on IRC, and got an answer within a few minutes. When i was having some trouble with it (i got a link to a slightly outdated documentation page), a different person (Bartosz Dziewoński again!) was willing to give me some walk-through help which solved my problem. If and when i have some free time, i might just go and update that documentation page. (It’s here if anyone else wants feels like fixing it first.)

To close, i’d like to thank all the mentors who volunteered their time and effort to help out us highschoolers. Granted, they’re getting a lot of free labor, but… I decided that even though i realize i’m giving a lot of volunteer work, it’s a) for a good cause and b) might let me get in my 10,000 hours even before i turn 18. I can’t promise i’ll come back to work on more bugs without even getting a T-shirt, but please do feel free to add me as a reviewer to changes to code i’ve worked on.

Happy coding!

This work by Scimonster is licensed under a Creative Commons Attribution 4.0 International License.