Support paths in FindFirstChild and WaitForChild

[gillern]

Currently using :FindFirstChild() or :WaitForChild() is annoying for developers to use. It takes a longer to type and bloats code. Supporting paths in FindFirstChild and WaitForChild would fix this and would make updates New Content Property on TextObjects like this less problematic

local PlayerGui = game.Players.LocalPlayer:WaitForChild("PlayerGui")
local CashFrame = PlayerGui:WaitForChild("ScreenGui.Folder.Frame.Cash")

[sjr04 (uep)]

What about for games that actually name their instances this way? Could present the same problem. Ideally there should probably be a new function Instance:WaitForPath/FindFirstPath, but I do agree these conflicts can be annoying.

[ChipioIndustries (chipio)]

1000% this. I recall a survey looking into this a few years ago and pretty much everyone wanted it. It might be a good idea to come up with a method that doesn’t involve splitting the path by a certain character to prevent naming conflicts. Maybe have a separate function for finding an entire path?

Also, obligatory “I have a library that does what you’re looking for” link:

WaitForPath: A Solution To Endless WaitForChild Calls

If you’re like me, your interfaces are both a) not built with Roact and b) have a whole lot of nested components. As a result, spamming UI scripts with WaitForChild calls seems almost inevitable. Last year I wound up making a function to deal with the never-ending pain, and I’ve had a fair amount of success with it so I think it’s worth sharing here. It works by accepting the object to start searching from, and then an object path as a string, the same way you would write it to normally referen…

[ZeezyRed (UnwaveringResolve)]

I feel like a much better implementation would be an array of strings to avoid syntax conflict, but overall I agree that this would be a great feature to add.

[Fire540Games (FireForge)]

@ChipioIndustries

a method that doesn’t involve splitting the path by a certain character to prevent naming conflicts

Possibly making WaitForChild/FindFirstChild take any number of variables (I mean the things you put into the function, I don’t know the correct word for it), like print does.

Instead of this:

@gillern

local CashFrame = PlayerGui:WaitForChild("ScreenGui.Folder.Frame.Cash")

It would be this:

local CashFrame = PlayerGui:WaitForChild("ScreenGui", "Folder", "Frame", "Cash")

That would solve the problem of objects with . in their name.

[Halalaluyafail3 (FindFirstChild)]

@Fire540Games

local CashFrame = PlayerGui:WaitForChild("ScreenGui", "Folder", "Frame", "Cash")

WaitForChild and FindFirstChild take additional arguments after the name argument, so how would it interact with those?

-- example of other arguments
workspace:WaitForChild("Baseplate",1)
workspace:FindFirstChild("Baseplate",true)

-- would the variable number of arguments be used like
workspace:WaitForChild("a","b","c",1)
workspace:FindFirstChild("a","b","c",true)

-- or like this?
workspace:WaitForChild("a",1,"b","c")
workspace:FindFirstChild("a",true,"b","c")

It would be weird to have other arguments after variable arguments (do any other functions do this?). The 1 could be interpreted as an implicit conversion from number to string (passing a number to FindFirstChild and WaitForChild for the name implicitly converts it to a string) which would make it ambiguous as to whether the 1 is used for the timeout or as another string for the path.