unique flag for listOf

[travi]

in addition to uniqueOn for lists that are not objects

[trevtrich]

I was going to file something similar here. What would you think about just giving the factory an iteration number? The case where this came up for me was generating a list of react nodes and I needed a key for each item.

[travi]

i think my plan here was to do similar to what was done for unique by a key: basically if the generated item is not unique, drop it and generate another one in the next iteration. my hope is that this would hide the logic from the consumer to prevent the need to be smart based on something like an iteration number. am i not thinking of something that would make the number being passed to the factory especially valuable?

[trevtrich]

Totally reasonable. I like the idea of defaulting to the 90% case, but I do also like the ability to get some control over what happens if I decide that it's necessary like with an iteration number.

[travi]

can you help me better understand the 10% case that you are describing here? the more i think of the use case for unique, the more i'm convinced that it should only be for primitives (i'm not really even sure what unique would mean for an object other than not-deep-equal, which doesnt seem valuable here).

is what you are describing simply a separate use case beyond uniqueness?

[trevtrich]

Sure -- the specific case I mentioned above was one where I wasn't able to use the uniqueness methods, so I wanted to use an iterator so that I could create my own keys for react elements. It's less about this specific implementation and more about just enabling the iteration counter so that it ends up conforming to a very similar patter to how foreach, map, etc. can be used.