require("@game/ServerStorage/Module") or require(game:GetService("ServerStorage").Module)?

[wisdomhisdom78 (Wisdom)]

did recently see about require when it was red squiggly line and I’m interested about why it exists

[wisdomhisdom78 (Wisdom)]

wait this is wrong lemme uhhh redo the title

there

[nooneisback]

You mean require by string? It’s just how it’s done almost anywhere outside Roblox.

Instead of typing out:

require(game:GetService(ServiceName):FindFirstChild("child1"):FindFirstChild("child2"):FindFirstChild("child3"):FindFirstChild("child4"))

you can do:

require("@game/ServiceName/child1/child2/child3/child4")

[wisdomhisdom78 (Wisdom)]

why not

require(game:GetService("WhateverServiceHere"):FindFirstChild("child4", true))

?

[nooneisback]

Because you want child 4 insid child 3 inside child 2 inside child 1, not in some other folder elsewhere. It also won’t work with code completion.

[jakeboygamer64 (Catstronomical)]

There’s no need for :WaitForChild or :FindFirstChild unless your using the recursive :FindFirstChild(NAME, true). Futhermore, using :WaitForChild becomes redundant if your using it in the wrong context, and place. There’s a post by this person.

Appropriate use of :WaitForChild(...)

@DasKairo

It really depends on what you need it for (which isnt a lot), but a good rule of thumb is to use it when you can ensure the object exist/will exist within a certain time frame, as it has the ability to halt code when the object is not found because of a timeout.

:WaitForChild() in standard practice, should only ever be used on the Client when you can ensure the object exists. Unlike the Server which has everything loaded in, the Client needs to load in everything that is able to be Replicated for it, if your code fires very early, you will likely run into errors indicating that the object doesnt exists yet, which is where :WaitForChild() comes in, which waits until it finds the object, or until it reaches the timout.
Which in essense

1. Object Loads in
2. :WaitForChild() finds this item
3. Code functions as intended

Bad usages of :WaitForChild() that I can think of are:

• Server Usage
  The Server will always have everything loaded in, Waiting for something that is already existing is pointless, and just uses more resources, aka bloat.
• Sanity Checks
  If you are just checking if an Object exists, :WaitForChild() is an awful way of doing it as explained earlier, In order to perform a proper Sanity check with Instances, you can use :FindFirstChild(), difference being that it does not yield, and does not return an error if the object doesnt exist, with it instead returning nil, Because it returns nil, we can check for the Condition if Object ~= nil then, to perform this sanity check.

---

@Tiagogibbon2

Do i have to use :WaitForChild() for literally every single instance outside of ReplicatedFirst?

Most likely, but for a good reason.

ReplicatedFirst, is the first thing the Client will Fire Code from (Its in the name lol), before the Game has loaded in, which is how we are able to create stuff like loading screens with seemless transitions, and preload our games.

Because it fires so early, very little would have been replicated, besides the Services provided to you, so in order to ensure that you are grabbing an object outside of ReplicatedFirst, you need to wait for it to exist, and as expected, :WaitForChild() does this job perfectly, however if you wait long enough using some code that maybe yielded for a while, you might not have to use it, as by that point it should have already loaded in.

@Tiagogibbon2

after i use :WaitForChild() in an instance, do i have to use it again for their children?

Most likely not , but if any errors occur over it not existing (Its pretty rare for me, but i cant say the same for everyone else), then I would say use it, but this is something I dont see happening to often, so its a precaution worth taking.

---

The notations for string path requires support:

• @self/ equivalent to script.
• @game/ equivalent to game.
• ./ equivalent to script.Parent
• ../ equivalent to script.Parent.Parent.

Some advantages, assuming you don’t use external editors like rojo are the fact its much more shorter and cleaner than individually typing out its path with its FullName. With the obvious downside of ‘structural strictness.’

I only use string notations for ‘short requires’, or requires that don’t require me to always type script[NAME] or script.Parent[NAME]. However for code flexibility, I’d rather declare the paths of the Instances that get to it so, If in future I want to change one of the Instances, I can just change the variable I called to something like local ModulesFolder = ReplicatedStorage.Modules to local ModulesFolder = ReplicatedStorage.Framework.Modules.

[IIIIlIIlllIlIlll]

I personally prefer string requires but it’s honestly just preference or whatever your team uses

[2112Jay]

The for sure, for sure way ..

local mod = require(game:GetService("ServerStorage"):Waitforchild("ModuleScript"))

local mod = require(game:GetService("ServerStorage"):Waitforchild("child1")
	:Waitforchild("child2"):Waitforchild("child3"):Waitforchild("ModuleScript"))

I always use GetService for services when possible. I want it to error if the path is wrong, so I can see exactly where to fix it. Laggy loads can be a nightmare sometimes, and chaining WaitForChild makes sure it waits for the hierarchy to load properly. Of course, you can organize that a bit if needed..

local serverStorage=game:GetService("ServerStorage")
local mods=serverStorage:WaitForChild("child1")
	:WaitForChild("child3"):WaitForChild("child3")

local mod=require(mods:WaitForChild("ModuleScript"))