As a Roblox developer, it is currently inconvenient to fetch children or descendants of a specific class from Instances. As an example let’s say I would like to retrieve only the TextButtons that are children of a Frame as shown in the screenshot below
The Frame has a UICorner and a UIListLayout, so currently the method we need to use to skip them in our for loops is by doing this:
for _, instance in frame:GetChildren() do
if not instance:IsA("TextButton") then continue end
instance.Activated:Connect(onActivated)
end
By adding new methods to Instance such as:
GetChildrenOfClass()
GetChildrenWhichAreA()
GetDescendantsOfClass()
GetDescendantsWhichAreA()
It would allow us to write the code like so:
for _, textButton in frame:GetChildrenWhichAreA("TextButton") do
textButton.Activated:Connect(onActivated)
end
If this issue is addressed, it would improve my development experience as it would make it more convenient to achieve the same result whilst complementing the existing methods found in the Instance class and also subjectively improving the readability
This would be incredibly useful. I am always using a custom version of this via if statements in a forloop to filter out unwanted instances. I usually do this for UI buttons in scrolling frames that may have UI layout, padding, etc
In the latter thread, a staff commented we needed some advanced lookup system, but I disagree. Lua predicates would perform just as bad as looping, and any other regex-eque query is destined to be a bottleneck.
Just add these methods already. I guarantee you every seasoned programmer has ran into this at some point.
I agree in that an advanced path lookup might be overkill for cases like these, plus depending on how the API is implemented might also discourage some programmers from using it if it’s too complicated to operate
Keeping the methods simple to use (or in this case familiar, since most are already accustomed to using methods like FindFirstChildOfClass as an example) would be key in maximising the impact and adoption of this feature
We had many requests for specific lookup functions, it really seems like adding only the set from a specific topic will not be enough. And can’t add all of them since many of them are too specific.
Queries will help not having additional requests.
I think part of the frustration might stem from the fact that for a long time now, we’ve had absolutely no way to narrow down GetChildren. Yes, querying by class does not solve every use case one might have for filtering children, but arguably it solves most of them and makes even more at least cleaner.
Consider that if Roblox were to implement an advanced lookup system, it’d probably be a bit more verbose and take longer to get into our hands than what the OP is proposing. Why not add these as a simpler stopgap (that already covers many use-cases) instead of having to wait another 3 years for anything? (Your prior message on the topic of XPath was early last year, and since then we’ve heard absolutely nothing about it.)
it’s not about covering all use cases that is impractical, it’s about listening to community feedback, this has been an issue for many people over many years, i think it is a reasonable feature request when other Engines can and do provide other fundamentally basic and simple QOL features while Roblox severely lacks
I for one would appreciate this greatly because I wouldn’t have to reuse the same boiler plate code for every project I work on
Feel free to check the resource I just posted in the DevForum, even though it’d be great to have them added by default into the engine API, y’all can contribute and use my solution for the time being. Hope this solves the issue.
I firmly believe that prioritizing the methods proposed in the OP over a complex query system would be beneficial for multiple reasons:
Faster to get working for devs (on an order of magnitude, I might add)
Solves a very common issue/pattern in Roblox
Light on the eyes, its purpose is very clear at a glance
Could even be integrated with the type checker? (resolve child type to whatever you’re querying for)
Querying children based on more complex factors definitely has a place in the engine, and I look forward to seeing it implemented someday, but PLEASE don’t leave us empty-handed until that entire system is worked out. These are straightforward, would be used constantly, and would at least make things simpler until the XPath/XQuery vision is realized.
Wanted to note that since our last response, we have considered adding new specific methods instead of a query system, but unfortunately work in both areas is not prioritized right now.
