Baserow - Update Row action #1645

I'd used Java very minimally before signing up for this issue. I'd only ever done tiny JavaFX programs as part of a school course, but I'd been wanting to learn more. I had been learning a little bit of it on my own time so I had some level of familiarity with concepts like packages, access modifiers, dependencies, and Gradle, which is the build tool used by the project. Knowing these definitely made it a lot less intimidating going into this project. I understood the project structure because I'd learned how Gradle projects consist of subprojects and subpackages each with different build configurations.

My classmate Arina noticed we were both working on the same project, and she was kind enough to give me some pointers by linking to the developer documentation for adding a component, and to an action that had already been defined for the component, which meant I didn't have to look through the repository myself to find the relevant files/directory. But if I had to, I would've used git grep, GitHub's code search or IntelliJ's search. I did use git blame to check out the history of the component I was going to work on and saw that it was all developed in one commit.

The project's contributing docs were very easy to follow with detailed instructions laid out step by step. But the project appeared to be very young - I noticed a few README files that just said // TODO.

I tried to compile and run the program before I made my changes to see how it worked, but it was a rough process. Here's a glance at the notes I took:

After it finished compiling (having taken over an hour), I ran it so I could check out the existing component. I tried making an account to use the client but it wouldn't let me, so I went back to the contributing doc and found that it comes with an admin account that can be used for development, which I think is created when you run docker-compose.

Once I was logged in, I tried making a Baserow component, but the client was a bit slow so I accidentally made a duplicate. When I tried deleting it, the client froze, so I hit refresh, and started getting server errors and the client timed out. I tried restarting the server and client but it was taking a long time - seemed to me like it was going to take an hour again. After waiting for about 16 minutes I called it a night and decided I'd work on it later.

4 days later

I was dreading returning to this project and having to deal with the hour long compilation time but with Hacktoberfest nearing it's end I didn't have much of a choice. So imagine my surprise when the project built without errors and was up and running in less than five minutes. What changed? I have no idea.

So I hopped on the client and found the Baserow component.

Figure - The Baserow component and the existing actions on it

To add the Create Row action, I needed to look at the Baserow API documentation, which was linked to me by the maintainer. I had to make a Baserow account to view the docs which I thought was kind of odd but it wasn't a huge deal either.

So I tested the existing action, "Create Row", and ran into a bug where the whole page turned into an error message. I thought I entered an unexpected value but I'd later discover this bug was already being tracked by a separate issue unrelated to mine.

On a subsequent test attempt the Create Row action succeeded, so I decided it'd be a good candidate to study to try and understand how actions are created. I followed along by cross-referencing the issue, the existing action, and the contributing docs.

I learned that actions were created by defining the input parameters required, the output schema, and a method which defined the actual process the action performed.

In the Create Row action, I saw there was a method to get the fields for a row of the table, which was used to define the input parameters. I realized I could use this in my action, but it was named as if it was only intended for use for the Create Row action. I thought it made sense to use, so I went ahead and used it and decided I'd let the maintainers know.

When reading the Baserow API docs I learned that to update a row you use an HTTP method called "PATCH", which I didn't even know existed. A PATCH is like a PUT but instead of replacing the resource it partially changes it. Interesting stuff.

So I got to actually writing my action, and I was able to lift pretty much the entire code from the existing action. I only had to make slight adjustments to the parameters it accepted (I added a row ID to identify the row to update), the output schema, and the method it called (changed the endpoint and HTTP method). To allow for the row ID I had to add a constant to a file in the constant/ subdirectory which contained all of the constants related to the Baserow component.

I noticed all of the existing source code files had a license header, so I copied it into mine too. I organized my imports, formatted my code, and it was time to manually test it.

At this point I noticed the description for the Create Row action (the one that already existed) was wrong - it said it creates a row in a sample database in Baserow which it referred to by name instead of just saying you can create a row. I made a note to mention this to the maintainers too:

Figure - Incorrect description for Create Row component

My action showed up in the client and visually everything looked good:

The title and description showed up:

The properties (i.e. input parameters) showed up:

The workflow ran successfully and I received a successful response:

And the table was updated in my Baserow account:

I was satisfied with my changes so I went ahead and ran the formatter and tests, but the tests failed, because one of the tests expected the Baserow Component to only have one action on it. I updated the test to accommodate my new action, and ran a script which automatically generated documentation for the component. On rerunning the tests, they passed, but I still had to add a unit test for my action. I looked at the unit test for the existing component and was left scratching my head. I decided I'd made decent progress, so I called it a day, opened a draft PR, and let the maintainer know about the issues I noticed.

The next day

Even though the existing test looked scary, I didn't really have much choice but to add one for my action too, so I went back and tried to comprehend what was going on in the existing test. I looked a little bit into the testing libraries used - JUnit Jupiter and Mockito. I attempted to break it down bit by bit and used an LLM to help me understand what was going on on each line.

I marked my PR ready for review, and the maintainer accepted my changes! They provided some feedback - I forgot to follow some parts of the contributing flow even though I'd read them. For next time, I should review the contributing docs before creating the pull request.

I found the initial setup and writing the test to be the most intimidating parts of this issue. Actually adding the feature was a breeze in comparison. But what I found really cool about this issue was that I'd been able to contribute to a project in a language I didn't know that well, thanks to their well-maintained docs and easy-to-understand code.

And that was my last PR for Hacktoberfest 2024! Recap post coming soon!