[IMP] introduce collaboration feature

[EmilienD]

• Expanded rollup configuration and changed live and dev script to allow the use of node_module dependencies.

• add venv to .gitignore

• Build folder for development and adapt script

• Use uuid v4 instead of Math.random() based id

• Add socketio cdn link and "start collaboration" button to demo

• Remove lines that started a rollback when adding an unremovable node

• Adapt editor and server for collaboration through websocket

• Refactor "current step" management

  The current step was stored at the end of the historySteps array.
  This created a gotcha where there was no visible difference between a "commited" step and the current step that is not yet really part of the history.
  The last "commited" step was is the penultimate position in the array, which is counterintuitive.
  The current step is now stored in a property of the editor, and is accessed through a function in case this change proves to be wrong, it would be easy to reverse.

• Human readable history implementation. Magic numbers are a bad practice.

• User-based undo/redo. The _historyStepsState uses the step id instead of index for the edge case of an undo/redo step changing order because of the server reordering.

• Better serialization of mutations. Mutations were serialized using the final state of nodes, instead of using the state of the node at the time of the mutation.
  This commit cleans the nodes of their extra children, using the heuristic that if a node is already added or removed directly in a mutation, it should not be present as a child of an other node.
  When applying the mutations, we also reuse existing nodes instead of automatically deserializing.

[dmo-odoo]

On le renommerait pas uuid4 en l'important ? C'est confusing quand même de voir v4() je trouve.

[dmo-odoo]

C'est pas clair pour moi dans quel cas on veut sérialiser avec stropFromChildren et sans ?

[EmilienD]

Probablement jamais, stripFromChildren c'est un set de node à retirer des enfants des nodes qu'on sérialize. Le nom est un peu pourrave, si t'as une meilleur idée qui sonne moins comme le slogan d'un bar louche de Pattaya, je suis preneur.

[dmo-odoo]

Je comprends pas, si c'est une option qu'on veut jamais activer ou désactiver, pourquoi c'est une option ? ^^'

[EmilienD]

Qu'est-ce que tu veux dire par "option" ?

[dmo-odoo]

Je parle du fait que la fonction elle a un paramètre en +. C'est un malentendu en fait car je n'avais pas saisi que c'était un Set. Vu que son nom commence par un verbe, je pensais que c'était une option genre stripFromChildren: true / false, pour stripper je ne sais quoi depuis children, tu vois ce que je veux dire ? Mais en fait c'est pas une option, d'où le fait qu'on se comprenait pas :p Du coup faudrait p-e trouver un autre nom. Je propose childrenToStrip ou bien excludedChildren ? Qu'est-ce que tu en penses ?

[EmilienD]

Je suis vraiment d'accord avec toi qu'il faut renommer. L'idée c'est que c'est un set de node qu'il faut retirer des enfants des nodes qu'on sérialise, je vois pas trop cette idée dans childrenToStrip ou excludedChildren. Peut-être nodesToStripFromChildren ?

[dmo-odoo]

Je pensais que c'était les children qu'on strippait. nodesToStripFromChildren ça me semble bien du coup.

[dmo-odoo]

Je retirerais le code commenté, à moins que le commit soit toujours un wip ?

[EmilienD]

Ah oui j'avais oublié ce truc, faudrait que je voie si quelqu'un a une idée de ce que c'est censé être.

[dmo-odoo]

Remove commented line.

[EmilienD]

I'd rather not, it's there to document the explicit lack of action for that scenario. At first I left the actual code with the // do nothin' comment, but I felt it was a little confusing to actually test and branch on a condition where we do nothing.

[dmo-odoo]

Alors mettre un commentaire au dessus pour expliquer pourquoi on ne gère pas ce cas là. Histoire qu'on comprenne bien que c'est pas une ligne oubliée quoi parce que c'est à ça que ça ressemble pour l'instant... ^^'

[EmilienD]

C'est expliqué ligne 548.

[dmo-odoo]

Je suggère de distribuer le commentaire qui se trouve au dessus de la fonction. Plutot que d'avoir:

commentaire cas 1
commentaire cas 2
commentaire cas 3
code cas 1
code cas 2
code cas 3

Avoir plutot:

commentaire cas 1
code cas 1
commentaire cas 2
code cas 2
commentaire cas 3
code cas 3

Je pense que c'est mieux que de devoir switcher de l'un à l'autre pour bien comprendre.

[dmo-odoo]

Faudra rebaser la branche par contre. L'idée c'était de la merger en l'état puis de faire une autre branche pour le serveur etc ou bien tu comptes re-pusher dessus ? Je pencherais plutot pour la première option vu que t'as rien repushé sur cette branche depuis la review alors que je sais que t'as bossé, mais je préfère qu'on soit bien d'accord.