Memo schema tests

[ggirotto]

No description provided.

[ggirotto]

Just to point that I personally prefer id over uniqueId as I said when we were developing Flutter client, but we need to create a standard. Or everything becomes id or uniqueId. We already have uniqueId set as the property in the flutter models and collections json's

[matuella]

Yeah, and that's why I've created all of these structures using id, and not uniqueId. What needs to be updated are the collections, and not our current structures. uniqueId made sense where collections were stored locally and shared a unique id amongst all of them, even though they didn't belong to the same collection.

Given that, you can rollback to id no problem.

[ggirotto]

But should we update the collections jsons and also Flutter model to use id as well? Otherwise we'll use id in the server and uniqueId in the client. I highlight what I've said back in the client development that id implicitly means that's an unique identifier IMO, that's no reason to emphasis the unique stuff.

PS: We would need this minor refactoring in a separate PR instead mixing with this one stuff

[matuella]

Tests looking good!

[matuella]

Yeah, and that's why I've created all of these structures using id, and not uniqueId. What needs to be updated are the collections, and not our current structures. uniqueId made sense where collections were stored locally and shared a unique id amongst all of them, even though they didn't belong to the same collection.

Given that, you can rollback to id no problem.

[matuella]

Suggested change

	const memoContentValidationSchema = Joi.object({
	const memoQuillValidationSchema = Joi.object({

Just to enforce where we are taking these from. I think being specific here is beneficial.

Maybe also add a succinct doc?

[ggirotto]

Just to enforce where we are taking these from. I think being specific here is beneficial.

But aren't we going to follow the same format when we develop our own editor in #223? If yes, I don't see why would we enforce quill in the name here, since we plan to remove it in the near future

[matuella]

If we're going to create a custom format, it'll probably use quill deltas anyways, as it's a pretty solid and well-tested approach. Creating a brand new complex-object serialization + data-format is too much work. All available editors, if I'm not mistaken, use quill (i.e zefyr and flutter-quill).

[ggirotto]

Renamed

[matuella]

But should we update the collections jsons and also Flutter model to use id as well? Otherwise we'll use id in the server and uniqueId in the client. I highlight what I've said back in the client development that id implicitly means that's a unique identifier IMO, that's no reason to emphasis the unique stuff.

PS: We would need this minor refactoring in a separate PR instead mixing with this one stuff

I don't quite follow what you meant with "collections jsons", but yes, everything needs to be id since when we opted to update the strategy to use sub-collections of non-conflicting id's of these memos. The client will be eventually updated when the referencing models are mapped from firestore, as it's now mapping from flutter's assets folder + sembast local database.

[matuella]

If we're going to create a custom format, it'll probably use quill deltas anyways, as it's a pretty solid and well-tested approach. Creating a brand new complex-object serialization + data-format is too much work. All available editors, if I'm not mistaken, use quill (i.e zefyr and flutter-quill).

[matuella]

Lgtm