Migration to desktop application

April 1st, 2024

In its current state, the project does not serve the purpose I intended it too when I started. It is missing a few critical features, but I think the main problem is actually the fact that it is browser-based. Using indexed database to store the notes is fine at a glance but keeping the notes in sync with the repository is unreasonable and error-prone.

I propose that the best future for this project is to turn it into a desktop app with ElectronJS. This way, the project can interact with the disk and remove the indexed database as a dependency. Then, the project could interact with the GitHub APIs and actually create/update pull requests.

Naturally, with a migration of this scale, there is bound to a lot of work left ahead.

It would be nice for to implement an option for the snackbars to be manually dismissed. A small "dismiss" icon button could be a good stylistic choice to not overload the screen with too many actions.

However, the most natural way to dismiss a snackbar to swipe it away, but I have to idea how to implement such a feature at the moment. Alternatively, it might be enough to just lower the auto hide duration on the snackbar provider.

Notes

At the moment, the project uses IndexedDB to store pretty much everything except for the user data, which are stored as JSON file on the disk.

Since I love the idea of infinite scalability, I think I will try to migrate away from IndexedDB to SQLite or other embedded database.

Some observation

The project supports asynchronous read and write already due to the implementation of IndexedDB. As such, using Tauri API to communicate should not be difficult to integrate.

Also SQLite is a good candidate with generous size limit for TEXT-based queries at 1GB each.

The plan

The database of choice is SQLite. Tauri will expose critical API to the front-end, but the actual queries will not be exposed.

This means IDB will not be necessary anymore, but I will have to rewrite the IndexedDB module to work with Tauri API.

It might be a good idea to have an opt-in which automatically synchronize the cached database with the API on project startup. the syncing part is simple enough to implement with the project's current infrastructure, but missing part which would complete this issue is the feedback .

In the settings, when the project finishes the synchronization, it will trigger a snackbar feed to notify the user. This option should not be difficult to implement on its own. Additionally, the project should also notify the user that it is synchronizing the API with its cached database.

This feature is splits into a few sub-features which affect different parts of the app. The core of the feature is quite straight-forward. On startup, the app looks at the dates on which the cached databases were updated. If it was longer than a given threshold, the app updates the cached database. Else, it does nothing to avoid making excessive API calls to GitHub.

So far, I need to update two parts to accommodate for this feature.

• On the settings page, I need to add two settings, one to the auto update feature on and off. I also need to make a field for setting the threshold.
• On the actual App, it is most likely that I have to refactor the useUpdateCache hook to accommodate for this feature. At the time of writing, the hook itself is tightly coupled with the setting page. I will also need to implement the feedback system to inform end-users that auto update is working.

It might be possible to improve the fetching performance from APIs, especially the getRepos function which fetches elementary repository data along with the repo's readme. Due to the way GitHub provide their endpoints, one request will collect the project's metadata, and another will collect the readme since the readme file is technically a repository content.

I need to revisit this sometime soon for vanity's sake.

When a topic starts with a custom prefix, it will be considered as a special kind of repository property. These custom property will appear on a separate filter option.

The prefix itself can be customized in the settings.

Add an option to export tickets as markdown files

March 31st, 2024

At the moment, data is stored entirely on the browser. This is not the best practice, since the underlying database can be "purge", either accidentally while clearing browsing history or intentionally. Regardless, it means everything could be deleted in an instant.

There need to be a way to export tickets as actual files. Exporting one file should be straight-forward with modules like FileSaver.

Mass export should also be considered. The expected behavior of mass-exporting tickets is that they are bundled into a zip file. A module like jszip provides a way to write zip entirely on the browser.

An additional challenge to consider the interface, which has to be updated to accommodate for extra actions.

The nature of the project is inherently insecure, and it does not help that the project is hosted as a static SPA using GitHub pages. It is impossible to store any kind of credentials, the project cannot take advantage of GitHub Apps which uses client key, nor OAuth apps which also uses app id.

Thus the only reasonable resolution to the security issue is to setup a back-end somewhere, somehow. For now, that is the kind of commitment I cannot afford.

GitHub does not provide a way to easily group repositories together under a searchable group. GitHub does support a similar feature. For example, list all repositories which a user has starred. But you cannot create your own grouping.

This feature would be extremely useful to implement. Essentially, all that has to be implemented is another indexed database. The key could be the name of the group and the values will contain a list of repository identifier, namely, the full name of a repository.

Additional features are the CRUD functionalities, I should have the ability to create new groups, edit them, and remove them.

Under the api region in settings, it is useful to explicitly note that if the personal access token do not have the "repo" permission, the project will not have access to private repositories and their issues. It can be quite jarring when the project cannot see the private repositories.

In both RepoDataTable and IssueDataTable there is no explicit option to filter an option on mobile devices.

The README for this project should include;

• introduction
• motivation,
• disclaimer, and
• technologies.

The introduction part will talk about the "what." It is important to discuss "what" the project is early, so any possible contributors could understand the mission statement.

The motivation part will talk about the "why." Why did I develop this project?

The disclaimer part might have the first topic discussed due to the insecure nature of the project.

The technologies part will cover the future proofing, logs, and general book-keeping.

Also, it might be fun to include the origin of the name "Phosphophyllite" somewhere in the readme.

Implement an option to include difficulty and urgency levels in issues, also add a display to indicate a few urgent project on the front page.

The routing is absolute mess and is in dire need of a refactor, especially the RepoDetailsPage which is split into two tab using index. This page is doing too work with data display.