Diary of Working on Notas - Part III

Problem

Another week has passed, for someone focusing on doing something, the feeling of time passing is as fast as a blink of an eye. Work is still there, but turn around and it's already the end of the day, I'm sitting here and struggling to tell you about what I've accomplished in the past week.

It can be said that this week in general is lighter than previous weeks because I have solved the synchronization problem of the Adapter. Also the unification of data from the Adapter to LocalStorage. It seems to be working relatively stable, I no longer lose data while typing, and to know whether that is true or not, there is only one way to sit and practice on Notas every day. Surely, from now until the end, I will play the role of "guinea pig" until Notas is officially introduced to everyone.

Problem with Turso

As hinted, the first Adapter to sync online data is called Turso after the name of a SQLite server provider. Turso allows us to create SQLite servers to store data with an extremely impressive limit. For example, with a free account, you have 9GB of storage, 1 billion read queries and 25 million write queries. And you know what, since I started integrating Turso into Notas, I've only reached the number of 3 million reads and 3 thousand writes to the database. I think if I use it alone, I don't know when I will reach the given limit!

To connect with Turso, you have to use the drizzle library. This is a fairly new ORM but is proving to have many advantages. drizzle supports many drivers connecting to different SQL databases such as MySQL, Postgres, SQLite... to even Serverless-based databases like Cloudflare D1, Supabase, Turso...

drizzle also needs to declare schemas to map data. Initially, because I have not read all the documentation, I did not know how to optimize the schemas. Later, I realized that drizzle also supports mapping the type of data stored in SQLite to JavaScript.

The following example is a declaration for the folders table:

import { sql } from "drizzle-orm";
import { text, integer, sqliteTable } from "drizzle-orm/sqlite-core";

const users = sqliteTable('folders', {
  id: text('id'),  
  isDelete: integer('isDelete'),  
});

isDelete would normally take the boolean type in MySQL or PostgreSQL. However, SQLite does not have a boolean data type, so using the integer type with the implicit value of 0 is false, 1 is true is a way. Doing so, every time you query data, you have to go through a step to convert integer to boolean to switch to the data type used in the code.

drizzle supports type casting if we declare correctly. The above example can be simpler by just adding a mode declaration.

import { sql } from "drizzle-orm";
import { text, integer, sqliteTable } from "drizzle-orm/sqlite-core";

const users = sqliteTable('folders', {
  id: text('id'),  
  isDelete: integer('isDelete', { mode: 'boolean' }),  
});

Immediately drizzle understands that isDelete wants to receive a boolean value and it will automatically convert the data automatically in queries.

Problem with DaisyUI

In addition, I've just updated the dark mode interface for the application, but encountered a bit of difficulty.

As you know, DaisyUI is a UI library based on Tailwind. In Tailwind, to customize the interface according to dark/light mode, we can declare a prefix before each class. The example below declares the background color code gray-50 for light mode, gray-900 for dark mode.

<div class="bg-gray-50 dark:bg-gray-900">

</div>

But the philosophy in DaisyUI's design does not do so. According to them, declaring classes with dark/light prefixes will make the code confusing and recommend using common color codes. These colors are changed based on the interface you choose. Here is a list of recommended colors: List of all daisyUI color names | Colors.

You can refer to the discussion about this issue of DaisyUI at darkMode: 'class' doesn't appear to be honored by daisyUI | Github Discussions.

In addition, I also spent time looking at how to configure a PWA application, because I have no experience with PWA so everything is still very new. It turns out that configuring for PWA is more complicated than ever because it depends a lot on the browser and the operating system. For example, Android and iOS have very different configurations. The same feature but iOS always requires complexity and meticulousness many times more than Android.

This is the source that helps me learn about PWA:

• Progressive web apps | MDN
• Progressive Web Apps | web.dev

I have fixed many errors as well as optimized the interface for Notas to operate more smoothly. The logo has also been completed and will be announced in the near future.

Plan for next week

Next week, my plan is to optimize the interface for mobile devices, while optimizing the configuration for a PWA application, from installation to use to take place as smoothly as possible.

Finally, there is one more problem which is note encryption. I have researched two-way encryption for Notas, about the algorithm and how to encrypt. But first, let's make Notas work stably because encryption will be a layer at both ends of the input/output data.