astrimid - I wonder, Is there a way to use subc...

I guess, I could use group, but I then lose the ability to have my private namespace inside a component?

What I need is subcircuit that have ports but doesn't have a schmatic box?

no, group doesn't appear to have a namespace isolation

Maybe I could have a property `prefix` that I could prepend all my internal components with. Another possible approach is using `<chip`, but somehow hiding the chip and footprint and replacing it with a circuit in place. The simplest that could work is just a function that generates JSX, which essentially what components are?

Yeah, probably this is how it's intended to work? https://tscircuit.com/editor?#data:application/gzip;base64,H4sIAPXEYGoAA4VSy2rDMBD8lUXkkNDGsUPbQ7ADTWgvfRJ6yMEQu7ZSm8SSkRWaYvTvXUl+1BTak1Y7u7OjWdUkZyk9O7I6kwVJOKskPH2tT5XkxerIkwMEMK6BxQW9hCrJtnh3QS2wyMCvgpfVBIIl1CEDsATCe8Z6rIxGte5Uu40X9XDyC15rWBcIKk+CwVjHAP7SnhgJWuWoSRglQW0nKKzX6ZglNAiJ5x5CAnvOZSlyJjHjXrlzTGndQW3UT8FTMOt5k7iMk7wnttoUNPmO2WX3/3JfDLm7GVLECYW94EVQR86oE78Ep8zZPFIguUXa6RbxEGnpfBtMQqa0U/RcciEhpfv4dJQwNhswrvnvPBYpfOapzFDltVsUqDKj+UemVdt7SzrctHEgJKvHl/XD7rZ723Tey2j6htsIyWZ3t33DhuE6/tzG9MayNow/PAqJY/haf7AF/cFsIww/U2sQQlaZPzPPxhgdIuobc0nVctYCAAA= I guess, schematic is not code, after all, there's no encapsulation. Unless you're manufacturing a cusom silicon.

I think its a reasonable feature fwiw

Maybe there needs to be some abstraction that unifies chip, group and subcircuit. You have a subcircuit, such as `<Filter>` and then you choose how to implement it: IC chip, PCB circuit or schematic only abstraction without physical counterpart. Hm... Board and Subcircuit are a special case of Group? While Chip is unrelated?

I thought of a chip like a special case of subcircuit that is hidden from schematic and pcb behind a block.

semantically, both pcb board and chip are implementations of an abstract circuit. but visually, pcb represents traces, while chip represents components. This maps to my previous feature request, where chip doesn't have the ability to be represented as a circuit of 2 schematic components (dual package mosfet).

We have the internal circuit mosfet coming out if its not already out, also more features related to representing chips with multiple schematic boxes

Here's some imaginary API of a block having children schematic: ``` <Block name="U1" // "flat" -> No box; children drop right onto canvas (allows direct trace crossing) // "subcircuit" -> Draws a bounding box with ports/net labels // "symbol" -> Renders as a single IC black box / custom schematic symbol schematic="flat" | "subcircuit" | "symbol" // "footprint" -> Placed as a single packaged footprint (SOIC, QFN, etc.) // "sub-pcb" -> Pre-routed module / sub-board placed onto parent board // "none" -> Pure schematic logic with no direct physical footprint physical="footprint" | "sub-pcb" | "none" footprint="soic-8" // optional, used when physical="footprint" > {/* Internal logic & children */} </Block> ``` Does it sound reasonable?

This way, you could have a circuit to be compacted down into an IC chip, or a chip to be exploded into multiple schematic block that helps simulation and understanding, with a simple property change.

May be implementable without modifying tscircuit, if that internal circuit mosfet approach expanded into chip.

Yes but we have domain specific nesting levels, eg “schematicsheet”, “schematicsection”, “chip”, “internalcircuit”, the idea is right but for generic stuff yep can be in userland

I think schematic sheet and section is not exactly nesting, but more like an additional schematic view of the same source model? Similarly, PCB footprint doesn't include the chip per se, more like a shadow of a modeled integrated circuit. Not sure if children nesting is right model here. Board contains a circuit with components, and a chip can contain circuit. But schematic sheet with sections is only a view of a modeled circuit, while board and chip are implementations of it. Also, PCB view is only a model of the PCB, so you could potentially show how some System-on-a-Chip would be implemented as a separate PCB with connectors/pins. So board does contain IC packages which could contain a circuit with a die. And schematic pages do contain components and nets. But it doesn't mean the board or schematic is a model of circuit itself? The issue with current JSX model is it tries to have a single JSX element to represent disparate views, as well as model a netlist and generate BOM. For example if you want to map schematic of (U1A, U1B, U1C, U1D) to 1 physical PCB chip (SOIC-14), the model breaks down and you need to either nest schematic view into a pcb or somehow link multiple schematic components into one with referencing. `<subcircuit` forces both logical namespace and visual boundary with ports into one jsx element. When you want `<group` to have a namespace without forcing a schematic section, you have to do manual concatenation. There is a schematic sheet, but you need 1-to-1 references, as you can't display same subcircuit on two sheets? If we want two PCB boards connected together with connector, it splits apart a single electrical model into unconnected subsystems that can't be simulated together? Sorry if it's incoherent.

we almost always do better api design against real use cases- this is why we're trying to build a cell phone, laptop, steam deck etc. to test what challenges we'll hit along the way

i think we wouldn't "pre-empt" api design beyond what we needed for a project

because if we mess up the abstraction, we are forced to stick with it a long time

this is also to say, it's easy to discuss in the abstract and even useful, but when you get to practically making the thing it becomes a lot more obvious what the api you want is

fwiw w.r.t. U1A, U2B it works like this: ``` <schematicbox chipRef=".U1" name="U1A" schPinArrangement={{ ... }} /> ``` I believe that merged like 1-2 days ago

> <schematicbox chipRef=".U1" name="U1A" schPinArrangement={{ ... }} /> Is there some kind of schematic disabled property for `<chip>`? Or does this syntax handles that?

if not, a workarond I can think of is assigning it to some non-existing/hidden schematic page.

I've tried using schematicbox and either I don't understand something or it doesn't put me closer to dual mosfet package: https://tscircuit.com/editor?#data:application/gzip;base64,H4sIAFnsYGoAA91WW2/aMBT+K0fRNME2rqWXIdKJS9eilZYC1YqUh5pgijViI8dRqSL++3zJxaHqNO1h0paHxOc7x/aX7xyfJHYIXeJdVYQ7p+2QYMu4gAlGvoAVZwF4DleG53jUo4QKzFfIxzAI6Mnx4Ox6+TxG/g/0hMecbUOIPQpAUYDbEApO6JOygy39YtsrxsRWGqKAhv76QQI0ChaYJ8C8AGz9RTFCAq8iJkwgQZjaMcX3irrPaChe0wYXShnpTwlbCXrOYHSjQwffK6eeo10ZcR0QMnF0cpS4FHuJ1lNjnhmKtW0UPCnbBNu33xC2DO65EZdjEXEKJTUG6JybJ0Bc+wCNKoyv5tNhv3sN09tZRdKDcbf/rXt5AaUrRJcbHMK434MNemGRgPfQux3BhlAMROCgDB9qUiuzXsdfk21qGHncWN2zCCkVopGsBkkI8zHi4kYL7sZSQisqU82Ns6HlVvq4sboXwbkG50Uw1Uv7UsMOIfQaLfAmdGOtVno12jJh00aSrPRqKvTyED1S6KB5gLb0CofosV7hED3RKxTX3WcsazJndtaaVZje9yr3N8MZdGHav7oYdWfDvszNg0lIR9YTDuSr+gu2y1d8Jkuxdj1H7pODa0ye1uIQVbmc4JUbP1bfmSQ+WqKZ3D4mnq7tUmXtxrq4K9AqOmSC1P0fVN+M/q6svTdk/fh/ydoxg7LuugAexTv9RVniFYo2Akq6k+nu1VkwxJeZ3sf1IPCcXOmWtpNl1TkZygaOqCBIyM9PhDYwup1+vZhB2smz5tV51UNTljolnnNnZdGkolHP3sSkIAPy06o4XKrNJzgkoWA8tLbkCXaw08TayYQg6itHo17PPXmH9Jx6qy6VL7LLK8SQO7PtvCVWPtukf0nL2uLPaTVOf0+0PqMUy/+JJeHysXkBwUCsMYTRohJRItRscxBBnkRV7raygqv/DfUvImlUJw04h6oMkWzkOgq605Cq+Py9DyY135qkADOpU9PlKMdlZ/8TEXemuRUJAAA=

As I understand, it doesn't actually model two mosfets inside a chip, it just models a visual block that is losely coupled with chip component? So I guess you can now draw schematic blocks independent from `<chip>` but you still can't have true model/domain view decoupling.

I guess, schematic and physical view are coupled together with abstract model by design? circuitjson has source, schematic and pcb separation, but doesn't expose ability to explicitly define these separately, and uses pcb and schematic aspects as proxies to modifying the source?

I understand that exposing 3 models explicitly at the react level would make reconciliation harder?

But we already have `<trace` and `<net` that are kind of interchangeable as it influences both pcb traces and netlists/netlables/schematic? And we have separate `pcb*` and `sch*` props that influence different aspects of pcb/sch view. So what is the actual problem with exposing the explicit source/schematic/pcb API? One could imagine Vue-like slots: ``` <Component name="Q1" mpn="DMN65D8LDW-7"> {/* Physical Aspect: BOM item + PCB Footprint */} <PcbAspect footprint="sot363" pcbX={10} pcbY={5} /> {/* Schematic Aspect 1: First MOSFET symbol on Sheet 1 */} <SchematicAspect sheet="PowerStage" schX={0} schY={0}> <MosfetSymbol name="Q1A" pinMap={{ gate: "pin2", source: "pin1", drain: "pin6" }} /> </SchematicAspect> {/* Schematic Aspect 2: Second MOSFET symbol on Sheet 2 */} <SchematicAspect sheet="Control" schX={10} schY={0}> <MosfetSymbol name="Q1B" pinMap={{ gate: "pin5", source: "pin4", drain: "pin3" }} /> </SchematicAspect> </Component> ``` Or you could expose some programmatic access to circuitjson? Currently, creating cusom components is limited to what tsicrcuit core/props provides, even if underlying simulaiton/pcb/schematic engine supports modeling anything.