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 should not affect the items or their server representation.
This change is necessary to allow multiple items with same id
that live in different collections.
For example, shortcuts have the same id as the inner reference they
point to. This was not possible before and would cause an overwrite
of the original value.
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 because the pricing response data contains location based data like
country, countryCode, pricing etc. Running it on different
computers will generate different data. To avoid this we
should test only the types of each property using `jest`'s
propertyMatchers
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.
by default running `npm run test:core` will only run unit tests.
E2E tests require setting up credentials in the .env file.
Until we figure out a way to streamline this whole process,
this is how the tests will be run.
