abstract-select: selectedIndexes accessor is missing

[NV]

abstract-select.js doesn’t have anything like selectedIndexes accessor from native’s select. Should it be implemented?

[aadsm]

I believe there's no need for it because it is backed up by a range-controller and all that info can be found there.

[NV]

Thanks for pointing out. However, I still couldn’t find selectedIndexes in the range-controller.

selection method has an array of items (e.g. [{label:"en", value:"English"}]) which is not quite what I want.
visibleIndexes is null.

[kriskowal]

@NV what value are you expecting?

[NV]

Numeric value, which is the index of the selected item(s). When the first item selected I expect to get 0.

[kriskowal]

rangeController.iterations.filter{selected}.map{index} with an optional .only() at the end for the single selection case.

[kriskowal]

@NV strike that. That might not work anymore. You might have to do rangeController.orgnaizedContent.enumerate().filter{^selection.has(.1)}.map{.0}.

[NV]

@kriskowal
There is a typo in orgnaizedContent. It doesn’t throw any errors, just silently return empty array. Not very debug-friendly.

It still returns empty array, I’m trying to understand why. Could you explain .filter{^selection.has(.1)} part? Particularly, what’s ^selection?

[NV]

^ is some sort of a parent operator. It checks contentController.selection. But what’s .1?

[kriskowal]

^ is the parent scope operator. the .operator{block} blocks create a nested scope, so you need to go up one to get back to your source object. .1 is equivalent to this.1 or this[1] and is an artifact of the fact that although a gets parsed as a property, 1 gets parsed as a number literal, but both .a and .1 get parsed as properties of the implied this. With most FRB operators, it is safe to use an implied this for any operand, e.g., odds <- numbers.filter{!%2} means !(this % 2). It is however unsafe to use an implied operand for + because of unary +, and there’s a pretty strong case for removing the implied this in most cases, so perhaps you should stick with this[0] and this[1].

[kriskowal]

To be clear in both JavaScript, with Collections loaded, and in FRB ['a', 'b', 'c'].enumerate() renders to [[0, 'a'], [1, 'b'], [2, 'c']].

[NV]

@kriskowal thanks for the explanation.

[kriskowal]

Pardon:

rangeController.orgnaizedContent.enumerate().filter{^rangeController.selection.has(this[1])}.map{this[0]}

selection is a property of the rangeController, an array of all the selected values from rangeController.content. rangeController.organizedContent is the input side for a Repetition, and is just content passed through various adapters for optional filtering, optional sorting, and Flow frustum culling with the rangeController.visibleIndexes, if any of those are provided. For the purposes of a <select> component, none of those are in use.

[NV]

I’d like to disqus: do we really need selectedIndexes at all? We already selected values:

"values": {
    "<->": "contentController.selection"
},
"value": {
    "<->": "values.0"
},

Shouldn’t it be sufficient? Off the top of my head I couldn’t think of a real-world example.

[aadsm]

I agree that we don't need it.
If someone finds a use for it in the future he can always use FRB to create it.

[kriskowal]

I agree with @aadsm.

A note that values.only() is more powerful than values.0 because it will be defined only when values.length == 0, and because of the two way binding, setting value would clear out all other values.

[NV]

Okay, I’ll just rebaseline the tests for montagejs/matte#27 then. Thanks.

[NV]

Closing as a FRB workaround had been mentioned above.