If you export a type, do all nested types get exported as well?

Help and Feedback Scripting Support
, , ,
#1

I was making a (semi-quick) module for a dialogue system for a module, and I had some types that were nested into another type.

I exported the “parent” type and tried to access it in another script, but I couldn’t see the variables of the nested types when checking the code. I’m wondering: Do I need to export the types that are included in another type, or do the types get carried over?

Code (only section that matters basically):

local guiFunctions = require(script.Parent.GuiFunctionsModule)

local dialogue = {}
dialogue.__index = dialogue
setmetatable(dialogue, guiFunctions)

type ValueForDisplay = {
	Value: Instance,
	NeededValue: any
}

type ValueToChange = {
	Value: Instance,
	ValueToChange: any
}

type Question = {
	Texts: {string},
	ValueForDisplay: ValueForDisplay,
	ValueToChange: ValueToChange,
	NextPosition: "number | Can be a string to go to specific name"
}

export type DialogueChunk = typeof(setmetatable({} :: {
	Name: string,
	Position: "number | The position of the dialogue chunk in the conversation, multiple can be in the same place, -1 to force end",
	Texts: {string}?,
	Characters: {string}?, --Unused for now, will be useful for having multi character conversations
	Type: "string | default Text | Text, Question |",
	Answers: {Question},
	ValueForDisplay: ValueForDisplay,
	NextPosition: "number | Can be a string to go to specific name"
}, dialogue))

And here’s an image of the problem:
Notice how question is shown here...

image
image702×111 8.66 KB

But the variables of question are not shown here

image
image839×115 11.7 KB

I haven’t seen anyone really use nested types (and firstly I’m a little worried I’m doing something unconventional; I’ll probably post my full code in code feedback to see if it’s alright) so I decided to ask this real quick while I’m still working on the code. Also (side question) is it ok to use types like this? I’m not sure if they’re un-performant if used en masse. Thanks!

#2

I wouldn’t call those “nested” types, but exporting a type just adds it to the public namespace for other scripts to access. There shouldn’t be any difference with how the type actually behaves.

It seems you’re using types just for autocomplete, though. You should go into strict mode to see if the types are breaking somewhere. Using that metatable trick might be messing other stuff up, also.

Types also have no effect on runtime, so the worst you can do is slow down the editor. Although, I would stop using string singletons to document fields, that’s not their purpose and is a recipe for disaster.

1 Like
#3

Oh yeah, I knew that there’s other ways to use types but I really just did it because of the convenience of autocomplete. I’ll see if !strict shows me anything for the code, thank you!

P.S: I actually asked someone about using descriptive strings as the type (since I rarely do use --!strict) and I decided to use it sparingly since it shouldn’t be too hard to fix if it does break the code in the future, but if it does cause the autocomplete to break for this, I may have to change my practice :((

#4

So far --!strict hasn’t revealed any errors that would allow the types to show autocomplete, although the code does work without autocomplete it it’s still a little frustrating :sob:

#5

I see what the problem is here–you’re trying to apply a table to a table type with a metatable attached. The two types are treated exclusive.

You could export a normal table type and try using it for autocomplete instead.