A faster way to code Gui

Resources Community Resources
, ,
#1

So i made a Module which helps you code gui faster.

The Module is called GlobalUI.

NOTE: THIS WORKS ON THE CLIENT ONLY!

Heres and example on how to use it:

Instead of doing this:

local PlayerGui = Player.PlayerGui
local Frame = PlayerGui.Frame
local Frame2 = Frame.Frame2
local Label = Frame2.Label

Label.Text = "Test"

You can do this:

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Players = game:GetService("Players")

local Client = Players.LocalPlayer

local Shared = ReplicatedStorage.Shared
local Packages = Shared.Packages

local GlobalUI = require(Packages.GlobalUI)
local UI = GlobalUI:Load(Client) ::{ [string]: GuiObject }

UI.Label.Text = "Test"

If you are using this in another Script after Loading the UI, you can do:

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Players = game:GetService("Players")

local Client = Players.LocalPlayer

local Shared = ReplicatedStorage.Shared
local Packages = Shared.Packages

local GlobalUI = require(Packages.GlobalUI)
local UI = GlobalUI:GetUI()

UI.Label.Text = "Test"

This is helpful if you want to access a GuiObject that is descendant of the UI and will take a lot of variables or code to modify.

This won’t work if you add a new GuiObject in the PlayerGui, but it’s really easy to fix by using another function from the Module.

Heres how to enable auto update for the UI:

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Players = game:GetService("Players")

local Client = Players.LocalPlayer

local Shared = ReplicatedStorage.Shared
local Packages = Shared.Packages

local GlobalUI = require(Packages.GlobalUI)
local UI = GlobalUI:Load(Client) ::{ [string]: GuiObject }

local DescendantAdded = GlobalUI:InitiateDescendantAdded(Client, function(New)
    UI = New
    return
end)

Now if you add an instance in the PlayerGui, it will update the table that has all of the Guis stored in.

You can disconnect from this event if you do:

DescendantAdded:Disconnect()

Get the module Here.

If you have any issues make sure to comment, i will try to answer them.

4 Likes
#2

How would the second one be faster?

Why don’t you just use Fusion for this… or you know, just have a decently organized script structure?

This is also a really easy fix, just listen to PlayerGui.ChildAdded and users won’t have to do this themselves

I honestly just don’t get why people would wanna use this over simpler, more fundamental ways of scripting.

It’s like trying to use a remote-controlled chainsaw to slice bread… like sure, I guess it’s easier for other scripts to access it, but… why not just put all the scripts in the kitchen and use a bread knife?

5 Likes
#3

Huge overcomplication, you just transformed 2 lines of code into 8.

local PlayerGui = Player.PlayerGui

local Label = PlayerGui:FindFirstChild('Label1', true)
5 Likes
#4

This is not type-friendly either.

7 Likes
#5

This is not any faster than the usual way, and it actually appears to be more troublesome - and performs slower.

1 Like
#6

that would be slower i think, cuz the findfirstchild needs to wait for that object

#7

this is faster in terms of coding not performance

#8

Fusion is a ui framework, and u need to make UI with it too, this is just for already existing UI. and its faster in terms of coding not performance

#9

How? It is much simpler to just structure your scripts normally and put them where the UI would be accessible (such as as a child of the UI) rather than using this kinda global framework (which can get absurdly messy when your project gets big)

#10

FindFirstChild does not, in fact, need to wait for that object (plus you only have to do this once and just store the instance as a variable)

#11

Im pretty sure it has some yielding thing when finding the object

#12

And even if it did, you still only need to do it once at the top of the script. I don’t get your point here

#13

Instead of doing a bunch of locals for the UIs, this just allows you to access all the UI in 1 script with low amount of locals, if you want to type-check this, you can just do local button = UI.Button ::TextButton or something. Its faster for me to code using this and less complicated than have a bunch of locals

#14

What?

You would still have to store variables for each UI object, how would it reduce the amount of var declarations you need to do?
Like, you’re telling me this:

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Players = game:GetService("Players")

local Client = Players.LocalPlayer

local Shared = ReplicatedStorage.Shared
local Packages = Shared.Packages

local GlobalUI = require(Packages.GlobalUI)
local UI = GlobalUI:Load(Client) ::{ [string]: GuiObject }

local label = UI.Label
local image = UI.ImageLabel

local someFrame = UI.Frame
local button = someFrame.Button
local canvasGroup = someFrame.CanvasGroup
...

is less locals than just doing this and putting your script under the UI:

local UI = script.Parent

local label = UI.Label
local image = UI.ImageLabel

local someFrame = UI.Frame
local button = someFrame.Button
local canvasGroup = someFrame.CanvasGroup

Like, why??

#15

First of all, why is your local script in a UI, thats just bad organization and UI takes a while to load, also you dont need locals for each of the variable, u can just do UI.Label instead of local label = UI.Label, also its easy to access from multiple scripts, rather than get the player, their playergui, the UI and the other things you need in it.

#16

Why would I want the script that handles my UI to be loaded before my UI does?

No???

I know, however I was doing a comparison between using your module and just doing it normally, even if I didn’t store all those objects as variables using your module would still be longer.

local player = game:GetService("Players").LocalPlayer
local UI = player.PlayerGui.UI

And if this isn’t fast enough for you, literally just use Fusion!
I still don’t get the purpose of this module as a way to script UI faster

#17

Theres a lot of reasons youd want a local script to load before the UI, like if you make a simulator with Zones, youd want to load them first, the doors to those areas even if the UI hasn’t loaded. You can have separate scripts for both, but IMO thats really bad organization of a game, ussually you need 1 server and client with sub modules to handle the rest. This is just a way of me doing things faster, its faster for me than get the player, their UI, also this module waits until your UI loaded before continuing the script. If you dont like it then dont use it, i dont see a issue with that.

1 Like
#18

Okay? But the point of programming is to make something work… And properly. I don’t want to write poor-performant code. Did you not think about that?

3 Likes
#19

You don’t need to make the UI with fusion, you can use their hydrate function on already existing objects.

#20

I’m sure that this is not a better option.