AppFlowy: Open Source Contribution

Introduction

AppFlowy is an open source alternative to the note taking app Notion and allows users to be in charge of their note data instead of relying on cloud services (such as AWS). AppFlowy’s frontend follows the Domain-Driven Design paradigm. It consists of the presentation, application, domain, and infrastructure layers. To make the infrastructure layer more portable, they decided to use Rust to implement this layer. In addition, the developers of AppFlowy chose to implement the other layers in Flutter. Flutter, an open-source framework programmed in Dart by Google, is a perfect choice to deliver a top-notch consistent native experience across devices, given that it supports multi-platform applications from a single codebase. The frontend is split into two components: the UI Component and the data component. AppFlowy’s mission is to make it possible for anyone to create apps that suit their needs. They aim to offer Notion's functionality along with data security and cross-platform native experiences.

In order to achieve their mission in providing data security and cross-platform native experiences, AppFlowy upholds three fundamental values: Data privacy, Reliable native experience, and Community-driven extensibility. Since AppFlowy is an Open Software project, it allows for free access to open source technology and provides community members with tools needed to learn real skills that are relevant in the global job market. The community-driven extensibility value that AppFlowy upholds creates a rich environment for collaboration and learning, giving opportunities to developers of all skills.

Project Context and Governance

My Contribution

My contribution to AppFlowy was to patch a bug. The bug was related to a feature in AppFlowy that allows for deleting and restoring a document page. When deleting a document page that is currently being displayed in the viewing window, the user is given an alert asking them if they want to delete or restore the document. The bug occurred when the document page was restored and then the user immediately deleted the document page again, the option to restore the document page was not invoked and the page was deleted without confirmation.

In order to complete this task, a strong understanding of the architecture of appflowy was required. As previously mentioned, Appflowy utilizes a Domain-driven design which consists of four layers: presentation, application, domain, and infrastructure. The programming language Rust is used to implement the infrastructure while the other three layers are implemented using Flutter. Since this bug was related to the Frontend of Appflowy, I needed to add additional code and logic to the presentation layer in order to achieve the expected behavior. In order to fix the bug I only needed to add 1 line of code (see below). The line of code I added basically forces the view to refresh after a documentation has been deleted. This call to refresh the view allows for the current document being viewed to be updated and thus allows the confirmation banner to be triggered.

QA Strategy

Since the task selected was related to a frontend bug, most of the testing was done manually. Flutter allows for hot reloading so I could always have the GUI running while working on the code. I manually tested and re-tested the part of code that I was working on. Every time I made a change to the code, I manually tested the widget I was working on. I also manually tested every other widget on the screen area of the application after making a change to ensure there were no regressions. After testing from my IDE, I would build the application for windows to insure that my patch did not have any issues integrating the frontend and backend. The process I followed is standard practice for AppFlowy developers as their unit test suites are not fully implemented.

When making a PR to the AppFlowy main repository, there are multiple QA checks that occur as GitHub workflow actions. Both the frontend code (written in Dart) and the backend code (written in Rust) is passed through a linter to statically analyze the code for syntax errors. Formatters are also used to fix any formatting issues and to keep the code style consistent and more readable. During this autocheck process, workflows build the app on linux and on macOS. This is done to make sure the patch does not effect building the app on other platforms. Commitlint is then executed to make sure that the commit messages follow the AppFlowy standard (see Project Governance). There are workflows for running Flutter and Rust unit tests, however the Flutter unit test suite is not implemented and is currently just building the app. The Rust code is also analyzed using Clippy. Clippy is a static analysis tool that is used to catch common mistakes and improve Rust code. It contains over 400 rules and is highly configurable. Clippy can statically check code for correctness, style, complexity, and performance.

Final Thoughts

Contributing to an open source project was a very new experience for me and I feel like I learned a lot from it. I have worked in industry during internships, but this entire process was more independent. This process of contributing to an open source project also made me more confident as a developer. Having a repository maintainer that I have never met before accept my work is an incredibly fulfilling feeling. Overall, I learned a lot from contributing to AppFlowy and I definitely intend on contributing more in the near future!

References