Add support for local storage

[gustafl]

The user's progress should be stored locally in the browser until the user explicitly decides to upload it to the server. This needs some thought. What happens with conflicting data?

[gustafl]

Look at this: https://app.pluralsight.com/library/courses/html5-web-storage-indexeddb-file-system/table-of-contents

[gustafl]

When persisting known words between sessions (so the highlights can be loaded again on the next session) we need to mark the words' location in the text of somehow. One way would be to store the section number (default to 0, for the first section), the section child number (for paragraphs and headers, also starting at 0), and the character offset from the beginning of the element. For instance, the word effet in the second paragraph would be 0:1:3, or just 1:3 (not sure if defaulting the section is a good idea).

The end of the word need not be marked out (there is already code for finding the end of the word in the $('article').click() event). However, the code for loading known words and doing the highlights again, need to be really optimized. Do some tests to see if takes less time if the endpoint of hightlights are stored as well.

This data should be stored in the local database only. My current thinking is that the UserDictionary is for the user's mental lexicon only, not for persisting data relating to specific texts.

[gustafl]

Forget the last comment. Storing word location data is fragile. The document may need to be changed/corrected, and that would lead to out-of-sync location data. And since a large majority of the words will be highlighted using the auto-highlighting method, it's hardly necessary to do it any other way for the word instances registered by the user.

[gustafl]

The format for local data storage has now been defined here.

[gustafl]

Closed by mistake. Reopened.

[gustafl]

All you need to know to work with Web Storage:

// Get LocalStorage object
var storage = window.localStorage;

// If key/value pair exists
if (storage.firstName !== undefined) {
    ...
}

// Create or update key/value pair
storage.firstName = 'Gustaf';

// Get value of key/value pair
var firstName = storage.firstName;

// Remove key/value pair (if it exists)
storage.removeItem(firstName);

// Get all keys
var keys = Object.keys(storage);

// Clear all key/value pairs
storage.clear();

// Using bracket notation
storage[firstName] = 'Gustaf';
var firstName = storage[firstName];

[gustafl]

The exception for QuotaExceededError is a DOMError with code 22. Not that it's likely we'll ever get one, but we should probably check for it anyway. And also make sure the user can't write strings of arbitrary length in any of the fields used in the local data storage specification.

[gustafl]

There's probably no need to support storage events. I can't think of any situation where you need to have multiple tabs open in this application.

[gustafl]

Local storage is now used for storing data necessary to load the GUI elements associated with a language.

[gustafl]

I've divided this task into 3 methods:

• saveLexeme()
• saveInflections()
• saveTranslations()

All of these are called using the saveForm() method. There will also be load methods mirroring these, but they are covered by issue #79. The saveLexeme() method is already implemented, except for overwrite handling (if we need it). The other two will have to wait for issues #30 and #31.

[gustafl]

Here are a few scenarios we need to support:

1. Saving a word

1. User opens document for the first time with an empty local storage (LS).
2. User saves a word to LS.

2. Loading a word in form

1. User has saved a few words to LS.
2. User clicks a highlighted word.
3. Word is loaded from LS into the form. If there are multiple meanings to the letter combination, it's possible to move between them in the form.

3. Loading a word in tooltip

1. User has saved a few words to LS.
2. User hovers a highlighted word.
3. Word is loaded from LS into the tooltip. If there are multiple meanings to the letter combination, they are all shown in the tooltop.
4. Clicking the word in the tooltip loads that word into the form. When there are multiple meanings, the one clicked is loaded into the form.

4. Updating existing word

1. User has saved a few words to LS.
2. User clicks an highlighted word.
3. Word is loaded from LS.
4. User makes changes to word.
5. User saves the changes to LS.

5. Loading a document

1. User has saved a few words and closed the document.
2. User opens the document again (or any docment containing known words).
3. Each known word is loaded. Words with multiple meanings are marked as conflicts.

I'm not sure whether it's a good idea to allow users to "resolve" conflicts and to save the conflict resolutions. I begin to think it's better to just show the places where an identical letter combination can mean different things.

[gustafl]

Consider canceling the storage of lexemes, inflections and translations in local storage. This complicates the solution enormously.