> placing and connecting drag and drop electrical components
This is where game engines are annoying. You have to do "collision checks" between your cursor and any points of interest, like a slot or a grid or a connection. Usually in a 2D use-case like yours, you can just do a geometry condition (if component.x > slot1.x && component.x < slot1.x + threshold...), especially while your UI elements are regular shapes. Engines are fast at doing lots of native collision checks in 3D and with irregular shapes too with an engine-specific "collider" for each element, as it's expected to do collision checks for almost every visible actor in every frame in a game.
> and the simulation itself
Depending on the eventual complexity of your circuit simulator, there are pros and cons to different approaches. My undergraduate electronics degree is fading from memory so I might not have the best advice here.
A purely node/actor-based computational simulator is one approach, which reduces dependency on the global manager with knowledge of the layout or handling of the computation. You have to define how each component responds to charge at its input nodes, and manipulates charge at its output nodes, ie, define its response curve in terms of charge. You just have to work with the differential time-equations for computational analysis of electric circuits, not the closed-form analytical ones. ie, substitute I with dQ/dt (charge over time) everywhere, and in every "update" iteration (or "tick" or "frame" or whatever your engine calls them) multiply the differential equation by timeDelta (every engine provides timeDelta as the time elapsed since the last frame). I would give this method a try scoping the project for very simple components (maybe just DC power source, LED, resistors, connector junctions) that can be sized to a grid of discrete sizes.
This can however feel like rediscovering electricity from first principles because traditional circuit equations usually don't work with charge or with time, since they're defining the steady state behaviour.
If you would rather work with traditional steady state electronics formula for each component type, I think your second solution is a decent approach, "passing the result on" from one node into the next (which is the same as making changes to the tree iinm?). Technically using the steady state equations renders ticks irrelevant, other than updating to reflect any changes in the circuit, or if you have time-dependent component behaviour (like an AC signal or an inductor), but that's still a nice feature to have.
I think you should try avoiding reliance on a global manager for anything that goes on in the simulation as much as possible, because I sense you will tend towards "centralized application logic" if you allow yourself that luxury. The whole point of game engines is to break down your logic into different actors that interact with each other, and a simulation is exactly that.