Daily Journal / Rich Text Note Editing

[mikhael28]

Vision - The ParetOS offers our Toans (or whatever we end up calling our users, I hate the word 'user') the 20% of software that will give them 80% of the benefits they need in their daily life. One thing that people need is the ability to take some notes, organize them by day and search through them (potentially with some sort of tag system, that allows us to organize things by theme.

Right now we offer (Full Stack Starter Kit) users access to the 'Notepad', which is just a Rich Text Editor that saves your notes whenever you navigate away from the notepad, 'onBlur' event. What I would like to see is a type of journal/note/todo list that is a simple, organized by day, journal that is saved in something of a real-time capacity (but the onBlur pattern can remain as a prototype). The idea is to give people the ability to store lists of things to do, organize their study plans, whatever - on a day, by day basis.

This item revolves around implementing that functionality, hopefully with an npm module that is smaller in footprint than quill.js (which currently occupies 250kb in the source-map-explorer) bundle.

1. We want Toans to write down items in a daily entry. If they did not start writing anything on that day, then that day can be skipped (or added, dependent on which is easier).
2. We want to store each day's entry as a separate object inside a 'journal' array.
3. We want a Rich text editor with a lighter footprint than quill.js
4. We want a beautiful, full page typing experience, with an easy way to shuffle between days.
5. Bonus: we want a 'tag' system, that is searchable. I don't think this is really necessary - perhaps we can make a custom entry/document per tag, that is readily available to the user.

There are likely more requirements than have been enumerated, this is just a first stab. Think of Roam Research, but a very minimal version of what they offer.

This is an 'ownership' item - completion of this item (fully) qualifies you to be a 'core' member of the team. All subsequent maintenance/bug fix/feature updates to this particular piece of functionality are to be your responsibility, since you know the code!

[akashshyamdev]

Could we use tinymce https://www.npmjs.com/package/@tinymce/tinymce-react?

[mikhael28]

@akashshyamdev this looks very promising - I will do some research tomorrow. Have you implemented it in the past? Or, do you know of any open-source projects/companies that use it in their tech stack?

[mikhael28]

Pell is a TINY rich text editor 4kb, that could be a good solution https://github.com/jaredreich/pell Squire is also small, like 49kb, but offers some interesting programmatic support to extend the basic rich text functionality. 200 kb less than Quill. https://github.com/neilj/Squire

I'm not sure using a SaaS product like TinyMCE is the right idea. In general, we want to build our own tools (and integrate with API's only where it's truly necessary). In many cases, we want to recreate the software that is a part of the crucial 20%, and engineer it in a performant but not obtuse way. Also, I don't want to pay for an API key haha I'm already paying for AWS fees, my time, etc so I would like to minimize the number of services we use unless it is mission critical.

[akashshyamdev]

Ok sure. Btw, if you don't mind me asking, I'm pretty sure most of the uses of this application(at this scale) would come under the free tier. Also, do you have any template you use while creating React (typescript) NPM packages?

[mikhael28]

I think it merits more research, because we will have to pay for a note-taking service one way or the other, whether through TinyMCE or through our own API's/database storage. Let's keep this option open - first, let's define the data model that is needed, and then we can pick the solution on those merits! I was thinking that each 'day' in the journal could be it's own entry, for example in a DynamoDB table. Any thoughts?

[akashshyamdev]

@mikhael28 Are we using a SQL or a NOSQL Database? MongoDB has a generous free tier which can be used for this. If we are using a noSQL DB, then we can model it like this:

user: {
  // ... user properties
 journalId: string,
}

journal: {
  userId:string
  days: [{}]
}

[mikhael28]

@akashshyamdev what if we wanted to use DynamoDB? Could you give me an updated data model based on that database?

[akashshyamdev]

@mikhael28 I've not worked with dynamo db a lot, but here's a model I think is both practical and scalable.

Here's why I think it works: It works even if a user has been regularly adding journals every day for several years(because we store entry IDs not the whole entry)

[mikhael28]

Thank you for taking the time to put a diagram together for me - very helpful, and a great example to the rest of the community. Looking at the model though, I think we can probably cut out the journal object entirely - in fact, the name of our DynamoDB table can be called journal, and each individual entry can be an entry. The journal object is actually unnecessary, you are likely still looking at things from an SQL mindset where everything needs to be linked in some way by a foreign key. All good, I thought like that for a while as well - until the full power of DynamoDB and NoSQL was illuminated to me.

Now, next question - what do you think our partition key (and type), and sortKey (and type) should be for this table? Do a little bit of research - if you have an hour and want to learn a lot about DynamoDB, I highly recommend this video: https://www.youtube.com/watch?v=HaEPXoXVf2k

[akashshyamdev]

Yeah sure, give me 2 hours and I'll get back to you on this(let me go through dynamo db) :)

[akashshyamdev]

I think our partition key should be the date, we store it in groups of weeks/months/years and we sort it from latest to oldest(so sorting key is also data).

[akashshyamdev]

Also, I was going through the application and I think the application could do with a UI revamp(nothing much, just fixing up spacing, alignment etc). So if you agree, I could design this in figma and we can open source the implementation of the designs. Let me know what you think @mikhael28 :)

[mikhael28]

Regarding the database schema, we should actually use the userId of the writer of the journal as the partition key, and the date of the entry as the sortKey. This will allow us to easily, through the dynamo API, get a list of all journal entries by a specific user, and specifically get/update/delete a particular entry using the sort-key. Dynamo will also automatically group entries with the same user-id close together, creating efficient queries.

Re UI revamp, if you have any ideas for new, updated design - go ahead and put something together on Figma. No guarantees on whether we can/will implement :)