Attendance:
- Jack Works (JWK)
- TechQuery
- Kevin Gibbons (KG)
- Michael Ficarra (MF)
- Richard Gibson (RGN)
- Chengzong Wu (CZW)
- Shijun He (JHX)
- Zhijie Li (LZJ)
- Andrew Rottier (ACR)
TechQuery: I have only one issue need to be discussed: tc39/proposal-array-unique#3 (comment)
TechQuery: I think we should keep the string key to ? parameter cause I think other array methods may no need to add a string key as parameter. Cause if we add a string param on this method it may confuse the dev how can i use it e.g. I have 5 similar methods with a callback param and if we add a string param to them, it will make it confuse to devs cause devs may thinking which one is the right ??? we should keep the elements, we ?? equal string value as string param all we get a value by the string key and test the value whether it's truthy
So this 5 methods aren't like our unique proposal. THis proposal need a string key for the most common cases most developers may use lodash / underscore to unqiue their arrays and this libraries provide a string param signature such as unique or uniqueBy or uniqWith. It’s convenience for devs to deduplicate most arrays so i think it’s a so easy way for devs to use the unique methods . Only Array.map may need to add a string param. This unique proposal is a so tiny proposal. I think we may not necessary to split this tiny proposals to 2 independent proposals to add unique itself and the second proposal to add key as parameters (to unique and other array methods)
MF: I agree with the reasoning here. I’m … that would be seperate proposal. I think we should pursue Array.prototype.unique assuming function param only.
KG: Yes, So I’d like to better understand why'd you like to add the version with the key param. It seems like a special case of function param. It's just like you passed x=>x.key into the unique. It doesn’t seems like that's difficult. I’d like to understand what motivation to add key param is?
JWK: hax mentioned a way to deduplicate by multiple keys, which is not a simple thing to write with a function parameter.
JHX: I think the reason why this proposal add a key cause unique by the key is very common case and use multi key is also common in database related things. In database SQL there’re composition key so it maybe a common case.
KG: I mean I agree it might be common. But function is fine for that case.
JWK: is it acceptable to add a new method like uniqByKey. They do the same function, why should they go to separated proposals.
MF: One of them is solve is unique array the other one is to dedup by string.
JWK: I personally think it is okay to not have key as a signature.
JHX: Personally I think it cloud be included in the proposal. A seperate method also okay. It can have one method, it seems there's no need to have 2 methods (uniq and uniqByKey). I’m okay if we don’t have consensus to adding a key sig. Cause since we can add it later. I guess the param will first check the type if it is not a func it will throw type error. So we can discuss this in the later stage if we …. Prove this is a common case we can add later.
KG: I agree with that assessment: we could safely add a index-key parameter later. I should say I don’t like the key parameter, because it seems like it's too much of a special case, but it is something we could safely add later.
JWK: It is already a common case. I do a quick check on Array methods. Map and filter also need this API style so maybe it ok to seperate a new proposal to enable this API style.
JHX: This is what TypeQuery discussed in the beginning. I agree with him that it's unlikely we'll have index on map and filter. It seems like not a very common case in those methods. I understand this is only the common case for unique.
JWK: I use the map to a property style map function daily, so if map or filter had this kind of shortcut it will also be ergonomic for me. It's not an uncommon case.
JHX: Maybe map. But filter I'm not sure what is the magnitude of that. What does it mean to filter by a key. Does it mean it should have the key?
JWK: It would test if the key is truthy.
JHX: Maybe. My point is that it's not very clear what the semantics are.
JWK: It can be discussed if we really want to add a new style to support all string-like use casing array methods.
TechQuery: I think only map makes sense. Other methods do not make as much sense.
JWK: Filter is also good for me.
JHX: There's another problem if we support multiple keys. It also has a problem in the map case: what does map return for multiple keys?
JWK: I would think it would pick some properties and compose a new object.
JHX: Maybe but the single key it just returns the value, if I understand correctly. So they're inconsistent.
TechQuery: Return value with one string key on map and return object with multiple keys so map will be more special case (if we do that). I think this kind of style only fit for the unique method. So the original name of this proposal is array unique but Jack raise the issue to me that MooTools already add a "unique" method to array prototype so i change the name to uniqueBy I read the threads of in ES Discuss I think uniqueBy is a better name I read the unique unqieuBy uniqueWith in the lodash and lodash has string key parameter and download count are very high.
A widely used API style in a community lib doesn't mean we have to bring it to the lang. Devs may want it.
JWK: Developers may want the feature to bring features of popular libraries.
KG: Lodash tries to provide methods for all of the common cases. It’s really not the style of lang APIs: the language tries to provide enough features so that it's not hard to do anything. unique is hard so we should add it. But if we already had the function style it would be easy to do the string key version.
JWK: Agree (with KG). Do you have enough info on this …. Any further concerns?
TechQuery: No more I just think the shortcut is so sweet.
JHX: I think the maybe we can first focus on the function style and for the key or multiple key cases maybe we need more evidence if they have worth to add to the lang.
And discuss the API style later.
KG: I think multiple key version is interesting. You could image solving it with something like records, though they probably don't work because they don't allow mutable values - although maybe they would, and then I would solve this using a function which maps to a record. I’m not saying it’s a good idea but it’s a interesting and complicated problem. The rest of the proposal is straight forward.
Waht kind of story we’d have for multi key issue. I don’t think multi string is ??? to it. As long as we’re discussing it’s not something for this proposal necessary.
I want to be open in the conversation so I often need to set up some background to understand I’d need to unique a complex thing than ??????? complex value not ???ed. Primitive is easy.
If I want two strings to be the uniqueness I can do that by concatenating those strings in a certain way, in a safe way. If they're a string and a number I can't do that safely, unless we have records and tuples, so they'd be a great solution. Except for mutable values. If records and tuples allow those it works but that proposal isn't currently trying to do that, so I'm kind of stuck. I'd really love it if the proposal could solve that problem, or if at least the proposal has thought through in the future how to do some sort of composition of feature selection to be used for uniqueness. Have the proposal champions considered that problem beyond the multiple key selection, which I view as insufficient to fully solve the problem?
TechQuery: I'm not ready to add multiple key style, but I'm thinking about it. I may design a new version to add it, but I'm not ready.
MF: I don't know what a solution would look like myself, I haven't thought through possibilities there. Before moving to later stages I would at least like to see the champions having thought through how we might do this in the future. Possibly if it's simple enough or generic enough, incorporating that capability in this proposal. But again I'm not interested in the string variant, because the properties might be deeply nested or I might want to map some function over it, so I don't think that version is sufficient.
TechQuery: You maybe map array with complicate obj elements first and then to unique it.
Possibly by some deep access / … to those props.
If you need to check deep property in the obj you may use a callback param to do.
MF: Yeah the problem I'm saying is that when it's a single property it works great. And when it's just primitives, records and tuples compare by equality. But that proposal doesn't currently allow mutable values, so it isn't a full solution. I think some solution needs to exist. It doesn't need to be in this proposal but we should document what kind of things we can explore in the future..
TechQuery: Tuple is great. I’ve read that proposal. We may add some additional features for tple and I’ll do it later thank you.
I can’t put complex values in a …
Documentation on how to resolve…
MF: I'd like that to be one of the possible solutions to this problem this proposal documents. But it's not inevitable that tuple and records allow mutable values, so it shouldn't be the only solution we discuss.
TechQuery: So index signature allows not only string but also number and symbol which can be the index key of the object we may support tuple to … multiple key or something.
I'll read the proposal next time after the meeting.
Is there any other questions left?
JWK: Nope.
RGN (in chat): I need to go, but I have a concern about keeping the first vs. the last item when consolidating objects (e.g., [{id:1, name:"foo"}, {id:1, name:"bar"}].uniqueBy(v => v.id)[0].name)
TechQuery: Which one you would end up with would normally depend on which implementation you used. If you did the "new Set" style you'd keep the first and drop others. I want to keep the first to match that. I just changed the proposal to keep the first.
MF: I guess I could see a possible optimization if you keep the last, so you can avoid checking before adding it to the map. But implementation concerns should be a low priority.
JHX: In some cases you have multiple updates. In such use cases you want to keep the last because you just ignore the previous updates and use the last for the final result. But that's just one use case, I'm not sure about other cases.
KG: It would be good to see what other languages and libraries like Lodash do. If they're all already consistent it would be good to be consistent with the rest of the world.
MF: I agree.
TechQuery: I'm checking what Lodash does…
KG: To be clear I'm not saying we have to do that right now. Just that it would be good to do it in the proposal and write down what you looked at and say either "they're all the same, so we're doing that" or "because they're different we can make either choice".
TechQuery: Lodash keeps the first one.