Multiple keys

[hax]

It's common to have multiple keys for unique, so let's also support Array<number|string|symbol> for the param:

let attrUpdates = [
  {node: nodeA, attr: 'x', value: 1},
  {node: nodeA, attr: 'y', value: 2},
  {node: nodeB, attr: 'x', value: 3},
  {node: nodeA, attr: 'x', value: 4},
]

attrUpdates.unique(['node', 'attr']);
// produce
[
  {node: nodeA, attr: 'x', value: 4},
  {node: nodeA, attr: 'y', value: 2},
  {node: nodeB, attr: 'x', value: 3},
]

[TechQuery]

I think it may be confused for users, they need to remember whether these keys mean && or ||. Just like the return value of .filter() callback, true or false, which one is the value to drop...

[hax]

I think "composite key" or "compound key" is common concept in database?

[Garbee]

I think multiple keys aligning with a composite key from databases is a good concept to have. In the example given here however, the last in was taken as the value to keep. Where in the current typical cases shows the first in being the value and once set not overwritten.

For consistency nodeA and x here should have the produced value of 1. First in is kept and left unchanged.

My only other concern to flush out is how would undefined values for any given attribute be expected to work? At least with PostgreSQL you can't have nullable/undefined composite keys (at least for primaries but probably for any usage as well.) So borrowing from that example, the DB would enforce the data never be in a state to cause a problem. But with JS, the gate is wide open.

If a reasonable solution to undefined/null can't be figured out, then I don't see why we should include this in JS. I'd much prefer we introduced easy to reason about basics in the language while allowing developers to do anything more advanced they want. Which the composite key thing totally is with a custom function.

I think the difficult issue is context with these values. In one context a developer may say, "I don't care about anything with those values in a key, leave it out of the resulting array since they can't be guaranteed unique." While in another context it may be, "I only want the best attempt at full uniqueness. If anything is missing, take the first whole compatible object and move on." So the same composite key scenario could be applied in different ways in our world. How do we rectify this without some extra option parameter?

[hax]

the last in was taken as the value to keep. Where in the current typical cases shows the first in being the value and once set not overwritten.

Let's discuss it in #18 .

[hax]

I raise this issue because there is no simple way to deal with multiple key. But maybe it could be solved by leverage the new tuple/record proposal, though we need to figure out how to handle object reference in tuple/record.

attrUpdates.unique(v => #[v.node, v.attr]); // not work now, because v.node are objects