The latest updates on your projects. Learn more about Vercel for Git ↗︎

@jrasm91, @uhthomas Open a PR for review of the backend part when I am starting to work on the FE

@jrasm91: Personally I think the client can indicate the primary person. People are sorted by count so the web could always use the first named person to achieve the same thing. The server code would be a lot cleaner if it worked like that.

Apologies for my unsolicited opinion, but I personally think there could be value in allowing users to customize the order of people in their people page - hence, I think abstracting away the merging logic to the server could have its benefits.

Apologies for my unsolicited opinion, but I personally think there could be value in allowing users to customize the order of people in their people page - hence, I think abstracting away the merging logic to the server could have its benefits.

The only difference between merging Person A into Person B opposed to merging Person B into Person A is:

• You keep Person A's name, instead of Person B.
• You keep Person A's thumbnail instead of Person B.

I don't see any advantage/benefit to adding a lot of complicated code in the server in order to automatically infer who's name and thumbnail you want to keep. Specifically by looking at asset counts. IMO it should be specified in the API request, by the client, and I think it would work fine if the web just used the first selected person or the left-most person with a name as the algorithm for that. The complexity server-side would be considerably simpler.

(even in the case the user got it wrong, the name and thumbnail can be easily changed after the merge too)

I don't see any advantage/benefit to adding a lot of complicated code in the server in order to automatically infer who's name and thumbnail you want to keep. Specifically by looking at asset counts. IMO it should be specified in the API request, by the client, and I think it would work fine if the web just used the first selected person or the left-most person with a name as the algorithm for that. The complexity server-side would be considerably simpler.

(even in the case the user got it wrong, the name and thumbnail can be easily changed after the merge too)

It seems I may have slightly misunderstood your intent in your previous comment, my apologies. I agree with not using asset counts to determine the 'original' person - it does seem like a lot of work for what could be, to be frank, a coin toss (determinism is always better though); it might as well be specified by the client.