There are three ways about this:
Just close the relevant tabs
Try to save relevant state (scale, offset, netlist id) and then ask the server for netlist data
Since it can be reasonably expected that most users will have a local server running (which should be shut down on IDE close so as to not waste system resources), the chance of recovering netlist data from the server is quite slim. The optimal solution would be a third way:
Use the cached netlist that should still be available on the client, send it to the server for parsing and layouting, then have the server expand all nodes that were opened for this netlist. Either the server or the client should keep track (inside a file) of all the paths that were requested for expanding/collapsing. All expansions and collapses are then recreated on the server. The netlist is only layouted after this is complete. Preferably, this history file would be kept by the client. This allows the client to disregard previous artifacts if the underlying source code has changed.
An associated problem with this solution would be the loading times. Especially for larger netlists, the initial parsing can be several seconds or even minutes long (depending on netlist size and host machine capabilities, eg. IPC and available RAM). The loading time could be sidestepped (at least partially) by serializing the server state on shutdown. Since a significant portion of the initial server-side load time is spent recreating the signal routes and bundling single signals together, deserializing persisted state should be faster. This state would also need to be managed by the frontend, since the server does not (and never should) know about the source code the netlist was created from
There are three ways about this:
Just close the relevant tabs
Try to save relevant state (scale, offset, netlist id) and then ask the server for netlist data
Since it can be reasonably expected that most users will have a local server running (which should be shut down on IDE close so as to not waste system resources), the chance of recovering netlist data from the server is quite slim. The optimal solution would be a third way:
Use the cached netlist that should still be available on the client, send it to the server for parsing and layouting, then have the server expand all nodes that were opened for this netlist. Either the server or the client should keep track (inside a file) of all the paths that were requested for expanding/collapsing. All expansions and collapses are then recreated on the server. The netlist is only layouted after this is complete. Preferably, this history file would be kept by the client. This allows the client to disregard previous artifacts if the underlying source code has changed.
An associated problem with this solution would be the loading times. Especially for larger netlists, the initial parsing can be several seconds or even minutes long (depending on netlist size and host machine capabilities, eg. IPC and available RAM). The loading time could be sidestepped (at least partially) by serializing the server state on shutdown. Since a significant portion of the initial server-side load time is spent recreating the signal routes and bundling single signals together, deserializing persisted state should be faster. This state would also need to be managed by the frontend, since the server does not (and never should) know about the source code the netlist was created from