This is more in line with how auth works:
1. You send a request with credentials
2. The server responds with an access_token
The only difference in this approach is that the client
cannot decide which scopes it wants.
this is better design wise as we won't have to keep checking if the
indices have been migrated or not. We'll just check the database version
and do the appropriate migrations based on that.
Since HTML is a tree-like language it is futile to compare it character
for character. `html1 === html2` is almost always false. This commit
introduces a simple diffing algorithm that only checks the text inside
the html + a few other attributes to decide whether the 2 HTMLs are
actually different or not. This is obviously not foolproof and it will
ignore everything aesthetic (b, em, strong tags etc.). This is actually
desireable because in our case only the text difference should
warrant a conflict. Everything else can easily be brought back.
Similarly, this also ignores whitespace differences surrouding the
tags.
All in all it'll provide a more reliable alternative to MD5 hashing the
2 HTMLs.
this was not exactly a bug but it can cause a lot of unintended
behaviour. Previously, you'd have to manually specify which version the
item migration should jump to. This was buggy and poorly designed.
This change makes the item iterate over all the db migrations one by one
automatically.
For example:
An item at version 5.2 will go through:
- 5.3
- 5.4
- and so on
this adds reslience to the sync logic in cases where network
isn't responding or is very slow to respond. Previously there were
cases where the sync would get stuck in Connecting state.
This will no longer happen.
This is a BREAKING change in the core & will require updating the
clients. The way it works is instead of keeping noteIds of all the
notes in the topic, it keeps an in-memory cache. This in-memory
cache `topicReferences` lives in the notes collection & decouples
notes from notebooks/topics. This also simplifies all the different
actions where references would persist after the note was deleted.
Since the note acts as the source of truth for where it currently is,
there is nothing else to do except rebuild the `topicReferences`
cache.
