Fix deletion of additional emails

[Pytal]

Fix #31164

Using index as the key would cause data from a deleted email to persist into the additional email at the same index due to the component being reused, this is resolved by forcing component replacement with unique string keys

[Pytal]

/backport to stable23

[Pytal]

/backport to stable22

[Pytal]

Now uses https://lodash.com/docs/4.17.15#uniqueId to generate the unique key

[Pytal]

/compile amend /

[skjnldsv]

Now uses lodash.com/docs/4.17.15#uniqueId to generate the unique key

I don't like the idea of using lodash. Relying on external libraries for things as simple as this isn't really the most efficient move I would say :)

Just doing any Math.random().toString(36).substring(2) like you did is enough imho.
Importing uniqueId doesn't adds much (82B vs 39B), but it's just a good pattern I thik. In the end we should move away from lodash, jQuery and other "tooling" libs that vanilla js can do noaways 😉

[PVince81]

Now uses lodash.com/docs/4.17.15#uniqueId to generate the unique key

I don't like the idea of using lodash. Relying on external libraries for things as simple as this isn't really the most efficient move I would say :)

Just doing any Math.random().toString(36).substring(2) like you did is enough imho. Importing uniqueId doesn't adds much (82B vs 39B), but it's just a good pattern I thik. In the end we should move away from lodash, jQuery and other "tooling" libs that vanilla js can do noaways wink

I thought it was already imported as we used it in other places. Let's not import it then.

My worry was more that more frontend developers will invent their own key algorithms in various places (with a certain risk of collisions), so perhaps we could add a method in the "OC." namespace that does the equivalent of what lodash does, so that every app dev can use it.
As far as I remember lodash uses a prefix + number and simply increments a number for every call, so it doesn't risk any collisions

[PVince81]

(the latter comment was provided to you by someone who's used to chase ghosts, aka bugs that seldom happen and still caused nasty issues, so I'm usually trying to be more careful about probabilities as I tend to be unlucky there)

[Pytal]

I don't like the idea of using lodash. Relying on external libraries for things as simple as this isn't really the most efficient move I would say :)

Yes I did Math.random().toString(36).substring(2) as this was my thinking as well, changed it back now

My worry was more that more frontend developers will invent their own key algorithms in various places (with a certain risk of collisions), so perhaps we could add a method in the "OC." namespace that does the equivalent of what lodash does, so that every app dev can use it.

This is a valid concern but as stated above by @skjnldsv something as simple as unique id generation without any business logic specific requirements does not warrant another abstraction. Whether we make a shared unique id generation method or not is outside the scope of this specific PR and any discussions should be started elsewhere

[PVince81]

👍

[PVince81]

@Pytal please resolve the conflicts, not sure if rebasing is necessary considering possible recent changes on master

[Pytal]

/backport to stable24

[backportbot-nextcloud]

The backport to stable23 failed. Please do this backport manually.

#33035

[backportbot-nextcloud]

The backport to stable22 failed. Please do this backport manually.

#33037