# astrimid - schematicbox doesn't suport schSecti...

Channel: #support
Source: https://discord.com/channels/1233487248129921135/1529854582530773012
Started: 2026-07-23T14:15:56.363000+00:00
Last activity: 2026-07-23T18:23:34.283000+00:00

## astrimid — 2026-07-23T14:15:55.799000+00:00

schematicbox doesn't suport schSectionName. Autogenerated bug description:
```
The <schematicsection /> documentation states that "any component that accepts schematic position props also accepts schSectionName." schematicsection.mdx:67-75

Since <schematicbox /> accepts schX and schY, it should theoretically support schSectionName according to this rule. However, the explicit props table for <schematicbox /> doesn't include it, which suggests either:

The prop is supported but missing from the documentation
<schematicbox /> is an exception to the general rule
```

## astrimid — 2026-07-23T14:18:01.534000+00:00

```Type '{ schSectionName: string; }' is not assignable to type 'SchematicBoxProps'.
```

This is what editor parser says.

## astrimid — 2026-07-23T14:19:28.660000+00:00

the compiler ignores any properties that don't exist, not even a warning

## astrimid — 2026-07-23T14:21:33.652000+00:00

I guess editor linter stage and the eval/runframe are not doing the same thing?

## astrimid — 2026-07-23T14:27:07.106000+00:00

My intuition says that all `sch*` properties should be present in some schematic props interface that should be implemented/inherited by all components that support them? This potentially creates a  self referential problem, but maybe nesting sections is a good thing? Nesting schematic sheets probably doesn't make sense, but schematic sheets can't be positioned either, so `schX`, `schY` and `schSectionName` should live in the same interface I believe.

## astrimid — 2026-07-23T14:59:14.778000+00:00

The workaround is to use another component and just treat schematic box as an overlay. But it won't expand the section size so that schematicbox will fit:
Attachment: image.png — https://community.tscircuit.com/media/1529865483073880205

## astrimid — 2026-07-23T15:02:41.168000+00:00

<@809856037376491570> take a look at this as well

## Seve — 2026-07-23T16:57:56.385000+00:00

yep, we need to add to tscircuit/props so that it can be implemented in tscircuit/core

## astrimid — 2026-07-23T18:10:24.158000+00:00

Here's what I found: `SchematicBox` extends `PrimitiveComponent` and uses schematicBoxProps, which doesn't appear to include `schSectionName` and `schSheetName`. So the documentation is lying, there's no code enfoced guarantee that `schX` and `schSectionName` are in the same inferace.

## astrimid — 2026-07-23T18:12:33.787000+00:00

https://github.com/tscircuit/docs/blob/main/docs/elements/schematicsection.mdx#component-schsectionname

## astrimid — 2026-07-23T18:14:41.718000+00:00

or rather `schematicbox` change didn't update all the places where it breaks a convention

## astrimid — 2026-07-23T18:17:45.187000+00:00

Ok, schematicbox zod schema does include schSectionNmae:

```
export const schematicBoxProps = z
  .object({
    name: z.string().optional(),
    chipRef: z.string().optional(),
    pinLabels: pinLabelsProp.optional(),
    schPinArrangement: schematicPinArrangement.optional(),

    schX: distance.optional(),
    schY: distance.optional(),
    schSectionName: z.string().optional(),
    schSheetName: z.string().optional(),
```

## astrimid — 2026-07-23T18:19:16.916000+00:00

Ah, wait. Ok, I'm slow...
Attachment: image.png — https://community.tscircuit.com/media/1529915824041754785

## astrimid — 2026-07-23T18:20:55.132000+00:00

my claim stands though, there's no interface or schema that enforces the rule that everything that contains `schX` also contains `schSectionName`, it's all based on manually assured consistency.

## astrimid — 2026-07-23T18:22:23.633000+00:00

which I guess you can't automate, as each component requires custom implementation of its properties?

## astrimid — 2026-07-23T18:23:34.283000+00:00

But since props are merged before `core` implementation, I guess there's no guarantee that any version of `props` has a corresponding implementation in `core`