Deprecate DockWidgetPluginGuiInfo, and use a Dictionary instead

As a Roblox developer, creating a DockWidgetPluginGui is a very clunky procedure that I think could have been done better.

Right now the configuration is controlled by a data-type used exclusively for this class, called DockWidgetPluginGuiInfo. I have a few general problems with this implementation:

  1. The type name is quite verbose.
  2. If you only want to set a specific field of the configuration, you have to pass values to the constructor for all preceding arguments up to the argument corresponding with that field.
-- What's going on here???

local dockWidgetInfo = DockWidgetPluginGuiInfo.new(
	Enum.InitialDockState.Left,
	false,
	false,
	0,
	0,
	0,
	120 -- I had to pass default values in for all of the above, just so I could set the MinHeight!
)
  1. The arguments pertaining to the size of the window when its floating have to be passed in, even if the InitialDockState isn’t set to Enum.InitialDockState.Float
  2. At a glance, it isn’t obvious what the constructor arguments actually correspond to. You can only figure it out from documentation on the DevHub and existing examples.

So how can this problem be solved? Well, I think it might be worth looking into using a Dictionary instead of an exclusive type. By doing so, you can label the fields of your configuration in Lua, you can list the fields in no specific order, and excluded fields can just fallback to a default value.

-- This is much cleaner!

local dockWidgetInfo =
{
	InitialDockState = Enum.InitialDockState.Left;
	MinHeight = 120;
}

If the DockWidgetPluginGuiInfo.new constructor is updated to just return a dictionary with the fields set based on what values were passed to it, then the 2nd argument of Plugin:CreateDockWidgetPluginGui could be swapped out for a dictionary!


An interesting thing worth noting is that Plugin:CreateQWidgetPluginGui already uses a dictionary. Perhaps its ahead of its time? thonk

Function Instance Plugin:CreateQWidgetPluginGui(string pluginGuiId, Dictionary pluginGuiOptions) {RobloxScriptSecurity} [Yields]
44 Likes

If they do this, would it also make sense for them to do the same with TweenInfo?

2 Likes

I think TweenInfo is a special case, given that you can access it as a property in the Tween object.
It certainly would be nice for it to support being constructed with a dictionary though.

5 Likes

Yeah, maybe deprecate using TweenService:Create() with a TweenInfo argument, and have it as a return value in TweenService:Create() or just by accessing Tween.TweenInfo.

2 Likes

Small rant below (I agree fully with the op)

I hate these names with a passion. There is absolutely no reason to include the name of the superclass (PluginGui). Imagine if Part were called PartBasePart or TextButton were called TextButtonGuiButton (pretty damn stupid, right?). At least change the names of these to something less verbose; it’s incredibly annoying.

9 Likes

Agreed with the OP - this is seriously detrimental to my plugin dev workflow, since I can never remember the parameters I always have to pull up the wiki. Having a dictionary with named parameters would be so much easier to manage!

Roblox pls fix

3 Likes