Closed kapros closed 1 year ago
something like
async locators(): Promise<Locator[]> {
let ret = [];
for(int index=0;i<this._frame._queryCount(this._selector);++index)
ret.push(new Locator(this._frame, this._selector + ` >> nth=${index}`));
return ret;
}
in playwright-main\packages\playwright-core\src\client\locator.ts
?
something like
async locators(): Promise<Locator[]> { let ret = []; for(int index=0;i<this._frame._queryCount(this._selector);++index) ret.push(new Locator(this._frame, this._selector + ` >> nth=${index}`)); return ret; }
in
playwright-main\packages\playwright-core\src\client\locator.ts
?
pretty much, not sure about the exact technicalities like whether it should post or preincrement and whether it should use _frame._queryCount or the locator's built in count
Isn't it already available? I think it was implemented with locator.count()
and locator.nth(index)
https://playwright.dev/docs/api/class-locator#locator-count
https://playwright.dev/docs/api/class-locator#locator-nth
I think this issue can be closed. What do you think @kapros ?
Isn't it already available? I think it was implemented with
locator.count()
andlocator.nth(index)
https://playwright.dev/docs/api/class-locator#locator-count https://playwright.dev/docs/api/class-locator#locator-nth
I think this issue can be closed. What do you think @kapros ?
Hi @jfgreffier, not really, the issue is about returning an enumerable / iterable object (so that you can use a foreach / forOf loop, the functions you linked allow you to iterate yourself with a standard for loop. Not like this is problematic, but on the other hand, just like mentioned, an iterable would allow using language builtins for working with lists/arrays and so on.
I don't see this as necessary, as it can probably be done in the user land. Also, there are several ways to manipulate Locator lists https://playwright.dev/docs/locators#lists
If you follow this mindset quite everything can be made in user land :/ Seems to be very useful for a lot of people according to newly created issues
As for me, iterables are important feature. it's not every-day feature, but i found quite useful this feature, since in my project - we are works with excel-like tables. All elements are divs, we need to iterate each of them and get each value separately and assert each of them.
So my conclusion - this is a useful feature for tables and data-type representations in browser.
In my project we define function which do the same as for toArray
method.
This would make using Playwright
from Clojure
a pleasure, instead it's a pain.
java.lang.Iterable
is immediately converted to sequable
under the covers in Clojure, to be used in a functional way.
As Clojure is not meant to be used in an imperative way, a straight for
loop is not easy to fit into a lazy pipeline (bread and butter and idiomatic stuff in Clojure, even if the laziness needs to be consumed immediately given the backing locator).
A helper function for all Clojurists to copy and paste
and reuse until such time as this issue is resolved.
(defn seq-locs
"Just remember to extract all of it before the locator changes"
([locator] (seq-locs locator 0))
([locator n] (lazy-seq (if (< n (.count locator))
(cons (.nth locator n) (seq-locs locator (inc n)))
'()
))))
In Python, not being able to natively enumerate, iterate on (collection[i]) or use locators in for-each loops makes the code seem really non-idiomatic and non-intuitive. Not being able to call len(collection)
is really weird too. Definitely important. Here's an ugly patch to make it feel better:
# patch non-idiomatic playwright by adding support for 'len()', 'collection[i]' and 'for i in collection'
playwright.sync_api._generated.Locator.__len__ = lambda x: x.count()
playwright.sync_api._generated.Locator.__getitem__ = lambda self, idx: self.nth(idx)
playwright.sync_api._generated.Locator.__iter__ = lambda x: (x.nth(i) for i in range(x.count()))
async
it's a bit trickierAlready implemented enumerator in 1.29
version. For Reference: #11909 .
P.S. Im disappointed on playwright team, since when i was asking a question for "public roadmap". They was asking - "look at the tags for future version". See at #17409 . Okay, am look at the 1.29
version, no issues related 1.29
and enumerator
feature implementation.
Hey Team,
I think the Locator feature is really great, but what I think it lacks is some kind of enumeration. There are evaluations and stuff like getting text from all elements, but that's only a limited use case. While it is possible for us to enumerate by ourselves, I think we could benefit much more from a built in enumerator instead of opting for a for loop. This would allow plugging into more useful features of supported languages for working with collections much easier.
It would then be possible to enumerate in: