feat(core): zip.select and assorted predicates

[andon]

Implements the function

const select: (...arguments) => location => Iterable<locations>

The function is in curried form. It expects a variable arg-set that is used to select/filter starting from the current location.

Each argument can be:

• a 'string' which is interpreted as descending into a property. The property should have an element (or child elements)
• an array of strings which is interpreted as the predicate ofKind
• a function returning a list of locations (selector or motion function)
• a predicate function used to filter out nodes

Also implements the functions that can me used in the select function, in some of the following categories:

• selectors
  • ancestors an iterable of the location's ancestors; nearest parent first
  • descendants, an iterable of all descendants, depth-first, right-to-left
  • children an iterable of the location's children
  • childrenAt(key) an iterable of the location's children for the specified key
• predicates
  • ofKind(kind) a predicate function which will return true if the location points to an element the given kind

Closes #53

[coveralls]

Pull Request Test Coverage Report for Build 420

• 69 of 70 (98.57%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.8%) to 81.716%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
packages/core/src/zip/skele/selector.js	21	22	95.45%

Totals
Change from base Build 417:	0.8%
Covered Lines:	1204
Relevant Lines:	1413

---

💛 - Coveralls

[ognen]

Well, look at this:

> function* four() {
... console.log('up to 1')
... yield 1
... console.log('up to 2')
... yield 2
... console.log('up to 3')
... yield 3
... console.log('over')
... }
undefined
> var x = four()
undefined
> for (var i of x) {
... console.log('got', i)
... }
up to 1
got 1
up to 2
got 2
up to 3
got 3
over
undefined
> 
> var spr = [0, ...four()]
up to 1
up to 2
up to 3
over
undefined
> 

In other words, we can't use [...generator()] as it eagerly realises the generator. We could modify the signature of descendants to say it returns an iterable, not an array; but we will have to handle it downstream (in select).

[ognen]

Our idiomatic use of a keyPath so far has been to refer to a single child or multiple children under a key. E.g. uiFor('bla') will render a single child under bla or all children found there if it is an array.

We need to keep the same. Does elementChild do that? If it does, the name is misleading.

[ognen]

Also, I know you are trying to wrap your head around currying but

elementChild(pred)(loc)

Is just damn ugly. elementChild(pred, loc) please.

[andon]

I don't have any issue wrapping my head with curring. Ugly is your conversing with me, and also commenting on outdated code (elementChild has been childAt for a while).

The usage is changed as you suggest. Also, I will revisit childAt one more time, as it is the only thing that doesn't make select generic.

Regarding this:

Our idiomatic use of a keyPath so far has been to refer to a single child or multiple children under a key. E.g. uiFor('bla') will render a single child under bla or all children found there if it is an array.

No, we don't implement childAt like so at the moment.

[andon]

🤔 ... about the following requirement:

• a 'string' which is interpreted as descending into a property. The property should have an element (or child elements)
• an array of strings which is interpreted as the predicate ofKind

... even though it is implemented at the moment, it might be an unnecessary complication:

• The first requirement, descending into a property is not generic. We have two options there, to use the current childAt motion (an implementation that is not clear at the moment), or to use the childrenAt selector. Both of them are "skele" specific. select on the other hand, is generic.
• The second requirement, to use an array of strings, might not be better than just writing ofKind predicate. This is especially noticeable when both string (descending) and string-array (of-kind) are used together. You really need to think/know what the syntax means.

Maybe we drop this requirement?
@ognen What do you think?

[ognen]

You are right, it's a specific interpretation of some skele/app stuff. We could easily add a wrapper in skele/app of select that adds that convenience. I'm thinking stuff like below gets very readable ```javascript // this select('tabs', selectedTab, 'content', ['quote'])' // vs select(childrenAt('tabs'), selectedTab, childrenAt('content'), isOfKind('quote')) const selectedTab = t => t.get('selected') === true ``` Aslo, in my eyes `childAt` and `childrenAt` are somehow still the same fn. On Jan 7, 2019, at 21:33, Andon Sikavica <notifications@github.com<mailto:notifications@github.com>> wrote: 🤔 ... about the following requirement: * a 'string' which is interpreted as descending into a property. The property should have an element (or child elements) * an array of strings which is interpreted as the predicate ofKind ... even though it is implemented at the moment, it might be an unnecessary complication: * The first requirement, descending into a property is not generic. We have two options there, to use the current childAt motion (an implementation that is not clear at the moment), or to use the childrenAt selector. Both of them are "skele" specific. select on the other hand, is generic. * The second requirement, to use an array of strings, might not be better than just writing ofKind predicate. This is especially noticeable when both string (descending) and string-array (of-kind) are used together. You really need to think/know what the syntax means. Maybe we drop this requirement? @ognen<https://github.com/ognen> What do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#113 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAC_V3qMaUYwyo66S5LjKmYwEbbMxeB_ks5vA68bgaJpZM4WM0ye>.

[andon]

@ognen okey, I left it be as it is.

I also left select to have the "skele"-related behavior (ofKind and childrenAt logic). So it is "generic" when you only use functions, and when you deliberately use string or string-array, you use it with "skele"-specifics. I think this should be okey.

I deleted the motion childAt and we use childrenAt now. This should clear up usage we discussed. Also, all selector functions are now iterables.

Will merge it, unless there are some more comments.