Last night my phone shut down while I was writing on JournalBook, and this morning all the content appears to be gone. I'm guessing the IDB write failed and corrupted storage. I'm wondering if it might be potentially useful to write a second copy to a second storage medium as a way to prevent that. Thoughts?

sorry for this noob question but I have no time to check the code out — TL;DR... so can anyone tell me where is the data stored?... btw I am not familiar with IDB nor Preact.

Mozilla Firefox Latest

There is a settings gear in the top right that isn't clickable!

• Should we prevent users from adding/amending entries from previous days?
• Should we prevent pagination to before their first entry? If not, it might be nice to show a "No entry for this day" message instead of blank textareas/question fields
• Should we prevent users from navigating to the future through URL manipulation?

Far too easy to mistakenly highlight a day

It'd be great to show the day of the week in the date above entry fields. When going back through my entries sometimes I wonder if it was a Friday or a Saturday.

I was thinking that maybe the notifications API could be used to allow users to setup the app to remind them daily to write if they haven't.

This would be 100% opt-in in the settings, after which the app will request for permission to notify. I haven't used the notifications API myself yet, but I'd be more than happy to take a stab at it if it sounds useful.

In readiness for languages, better theming, markdown and more (referenced in #35), we need to store settings in a better way than localStorage. Given idb is in place, a new table is probably the best option.

A migration will be required for the new table, key names decided, and defaults set. Any existing settings should be migrated - that should just be theme for now. This can be run in the initial table migration.

Once created, the settings page can be hooked up to the new table.

on Ubuntu 16.04, after successfully running npm run build, when I run npm run serve, I get this:

Unable to read file: /users/home/<<myUsername>>/PersonalProjects/JournalBook/src/node_modules/idb/lib/idb.mjs

ReferenceError: IDBIndex is not defined
method: JkW7
at: /users/home/<<myUsername>>/PersonalProjects/JournalBook/src/node_modules/idb/lib/idb.mjs:87:0

It looks like is looking for node_modules inside src directory, but is actually in root of project.

Consider moving to .txt files

• The current day’s view should be the only one in constant “edit mode” and all other days should be disabled by default.

• A better empty state instead of the list of blank TextAreas for days that are not today and where questions.filter(q => q.answer.length > 0).length === 0

As of #35 and the initial HN thread there is an interest in providing an option to sync changes to external providers such as Google Drive, Dropbox etc.

I compiled a list of these options with a few remarks to discuss ideas and the current progress.

Dropbox:
Dropbox provides a method to create a dedicated app folder to store all the files an app needs. This way an app can't access any other personal files. Additionally the OAuth flow does not require any server side logic so the auth flow can be accomplished entirely on the client side. This way, JournalBook can store a single file, e.g. "journalbook.json" inside an user's app folder and simply overwrite it when exporting. @trys would need to create a Dropbox App and set the corresponding environment variables.

Google Drive:
The Google Javascript Client provides all methods to authenticate a user and fully interact with the Google Drive API. The most convenient way is to use the Google Picker. It's possible to limit the files shown in the picker to a certain mime type (application/json) to select a file the user wants to import/export. The selected file id is then stored locally and used to update(overwrite) the file
when the user wants to export changes. Unfortunately the picker does not provide an option to create a new empty file, so the only option is to create an empty file directly via the drive API. Therefore we might need to provide the user with an input to alter the default name of the new file ("journalbook.json"). For this to work, @trys would need to create a dedicated app in the google cloud console and supply the keys as environment variables.

GitHub:
GitHub would be an awesome addition imo. A user can log in via GitHub, choose/create a repository(private and public) and use it as storage. Changes in the local database can be serialized to json and pushed directly from the browser. GitHub does however require a server for the auth flow that stores the app's secret. That could easily be done with netlify functions since netlify is used to deploy JournalBook anyways. On the other side I don't think it is a good idea to directly couple this project with the requirement to deploy to netlify. Maybe a separate repo? Multiple options to deploy? Any ideas? Anyhow this option is not as important as the other two so it can be delayed.

All of the above can be seen more of importing and exporting rather then full blown syncing. The current import for files replaces the data in the local database. I moved the import/export methods directly into the db. This way the methods can be enhanced later without affecting the storage adapters.

The modified UI for the above options would look like this:

Maybe it's a good idea to do a PR with just local file and Dropbox first, since it's already working and google drive requires a bit more work...?

Open to any ideas and feedback.

Hi, nice project 🥇!
I think I found a problem on Firefox:

To reproduce:

• https://journalbook.co.uk/get-started on a new computer (or private window)
• Click one of the preset questions

Expected:

• question gets selected

Actual:

• nothing happens.

Error in the console:

InvalidStateError: A mutation operation was attempted on a database that did not allow mutations.
TypeError: n.state.db is null[Learn More]

What's the deployment/backup situation here? If I understood it correctly, JournalBook doesn't persist data in a database or local files but rather in the browser (IndexedDb). This is fine but if you are using multiple browsers (because I'm running JournalBook on a server) then you can't sync between them.

For deployment, I created a Docker image: https://github.com/omarabid/docker-journalbook
Nothing sophisticated there, it just runs the website in a container.

Next step will be to have the data backed-up automatically but I'm not sure this is possible with the indexeddb solution. Are there any plans to support other storage types?

Just a couple of suggestion:

1. Internationalization: Translations could get the product on more front pages than you think.
2. Localization: For example in Iran, Fridays are the end of the week and we have 'Shamsi Calendar'. Arab countries and, in general, Muslims have another calendar called the 'Hijri Calendar' (where Ramadan comes from). I'm sure there are more calendars out there as well.
3. A timer: I personally don't have a lot of time on my hand, but documenting stuff could help me more and more. A simple clock/timer on the page could be of great help so that I wouldn't lose track of time. Also, consider creating this in a way that people be able to select/create different clocks (digital/analog) and change the themes. or have a couple of options ready to go with the theme.
4. Although offline is good, simple option of syncing to dropbox/google-drive would be a great option. Still, everything should be on the client-side.
5. Markdown should be easy to implement, but a more advanced WYSIWYG editor, with a switch in settings, shouldn't hurt.
6. Todo lists should be easy to implement too.
7. We don't have letter-spacing in Persian, Arabic, Pashto and other languages that their alphabets have joined forms. It makes them ugly.
8. Also, there are a lot of amazing open-source fonts for better Typography.
9. All of these suggestions could be simple plugins that after activation get downloaded, so the site would be as fast as it is right now. I'm not saying you should implement them all, these are just open suggestions that need more polishing. Even google's version of Hijri/Shamsi Calendars gives me headaches! They are extremely useful, but nobody cares.
10. The ability to password protect the entire journal could come in handy.
11. Maybe even creating multiple Journals.

Let's figure out which ones to do and when to do them.
Even maybe look into crowdfunding for making these ideas real.
Copied from #33 .

After exporting the data, when reimporting, the order is lost

Behaviour I'd expect: the questions are still ordered by 'when' they where created (in ascending chronological order)

Behaviour I see: random order

I believe this has to do with the importing (

It's now possible! https://news.ycombinator.com/item?id=18877729