#Issue with TS for nested object

34 messages · Page 1 of 1 (latest)

forest jay
#

https://tsplay.dev/mL31bN

I've a deeply nested (at some point possibly recursive object) JSON tree. I'm trying to apply a type definition for this.

I've a link to a TS playground but the link is too long, hoping I can post in a comment.

At present, I can add any property to the top level object and it won't complain. If I comment out the defitnition I have for one property on that object attributes, then it'll start correctly warning about the bad data on the object. Wondering if it's related to the recursive nature of the type def of that property.

#

Link to TS playground too long to paste - in the pastebin above

valid marlin
#

dead link :/

forest jay
#

argh, thanks let me retry

valid marlin
#

fyi there's a site for shortening playground links, i believe it's called tsplay but not sure on that

forest jay
#

Ah gotya, nice one

#

tldr, any idea why commenting out the definition for the attributes property on the top level then applies the correct warning about the bad testing "foo": "bar" property I have on the object

valid marlin
#

At present, I can add any property to the top level object and it won't complain.
right, that's because ts allows excess properties

#

wait no

#

shoot im too tired for this hold on

forest jay
#

I don't think it's that, if you comment out the type definition for attributes it'll throw as I'd expect

valid marlin
#

i was focused on the error 💀

#

ok i think it's just because it's shadowed by the deeper error

#

if you remove the erroring object, its parent also generates an error

#

so i believe that kind of shadowing is preventing the top-level object from being checked properly

forest jay
#

ahhhhhh

#

ok, so there's an order to resolving these and side-affects

#

ok that's helpful thank you

valid marlin
#

seems like commenting out that line removes the inner error, which allows the foo: "bar" error to be checked

forest jay
#

Cool, thank you - as an aside - does this look like a reasonable way to define the structure of a JSON tree?

#

there's a few different shapes based on the level in the tree

split spruceBOT
#
That_Guy977#5882

Preview:```ts
export enum HTML_OPTIONS {
TEXT = "text",
RADIO = "radio",
CHECKLIST = "checklist",
}

export enum SHAPE_OPTIONS {
BOX = "bounding_box",
ROTATABLE_BOX = "rotatable_bounding_box",
POLYGON = "polygon",
POLYLINE = "polyline",
POINT = "point",
...```

valid marlin
#

this errors on foo: "bar" with the property in question not commented

valid marlin
#

like, the "Base" is derived from the top-level object, instead of actually being a base

forest jay
#

ah yes fair enough, we have some not great naming conventions i need to be consistent with

#

very valid feedback though, thank you!

valid marlin
#

i think it'd look a lot better if the type definitions were shifted around to represent the logical structure more clearly, as is i don't really know what to think about it

forest jay
valid marlin
#

well, all the other types would be derived from the Base, like i mentioned, for example

#

idrk what else tbh