0hmx - @Seve @Rishabh https://docs.tscircuit.co...

It shouldn't be deprecated for sure

You can have a circuit were you don't want the <subcircuit /> to be routed separately, but for representation we use a <group /> inside a <board />

Subcircuits do something undersirable by default, like isolating namespace as well as implying port scoping rules. Group allow to opt-in subcircuit behavior, as well as show as schematic box. There was a proposal to unify schematic presentation: https://github.com/tscircuit/core/issues/1348 Here's a proposal that touch on scoping that could hollow out subcircuit further: https://github.com/tscircuit/core/issues/2934 Subcircuit or subsystem or schematic section, whatever you call it, only useful conceptually and presentationally. Group, it appears implies semantic meaning that could actually can influence manufacturing

Probably there should be separate `<schematicGroup>` (renamed from schematic section) and `<pcbGroup>` (current group), each having their own hierachy logic. And probably an explicit `<namespace` that defines how refdefs behave across namespace boundaries

But nesting would be difficult, so you would need some duplicate instance refs

Subcircuits are supposed to have high isolation, groups have low isolation, schematicgroup and pcbgroup yes these make sense but it general i feel like group may have been a bit of a misstep

Isolation, Spatial and semantic grouping are all different

schematicgroup is _closer_ to a semantic grouping, but isnt necessarily a semantic group if done for schematic layout purposes

pcbgroup is imo mostly spatial

We already have this schematicsheet/schematic section instantiation, maybe something like that could separate the representation concern out: some schematic group that could be referenced in schematic without physically changing PCB or moving JSX children out of where they are

Yea the non-nested instantiation is a good compromise

the use case I'm using `<group>` right now is for moving a group of components on schematic without changing their spatial relationship, or how the ports/netlabels behave. So if subcircuit and group are merged, this use case would need some way to opt-in behaviour like plug-ins: relative coordinates, refdef scoping, port behaviour, pcb concerns.

As I understand subcircuit has behaviour by default I can opt out of. I'd rather have opt-in atoms I can build with.

Yea ill add some stuff to the spec today but imo just avoid group haha,

schematicgroup and pcbgroup with optional nesting is probably good

what's the recommended way for only changing to relative coordinates within a group? subcircuit with some property to disable namespace?

or maybe modifying children from react component?

No, that would be more of a group thing which again the support isn’t so good You could use schX offset math but yea no good

The problem with relative grouping in general is it confuses AI

AI is confused either way, haha

The other method is using Calc strings

I think that maybe the least confusing method

I think it's mostly lack of examples and ever changing API

Lack of examples, yes. But we don’t have that many breaking changes to the API (generally) the changing API is mostly just new features