@giangiac If you'd like, you can go ahead and open this PR.

One thing I noticed was that the commit history shows you the tutorial steps for building up the frontend piece-by-piece.

In the last few commits, the step-by-step frontend explored a different approach for adding and saving plaquettes.

• We defined a few areas thanks to the addition of "red squares".
  The central square represents a sort of "plaquette building area".
  The other squares on the right represent the locations where the plaquettes are stored.
• The red squares are just guides for the eyes and a plaquette can extend beyond them.
  Ideally, they corresponds to the basic cell used when templating the plaquette arrays.
• The qubits in a plaquette are marked as 'X', 'Z', or 'A'.
  X and Z qubits are data qubits and their label suggest the Pauli factor associated to them in the stabilizer.
  A qubits are ancilla qubits.
  Their label also includes the relative coordinates w.r.t. the top-left corner of the relevant red square.

On the circuit-writing function

Currently it is just a placeholder and it assumes that:

• there is a single ancilla qubit
• it is possible to apply a CNOT between every data qubit and the ancilla
• the gate timing is fixed and the order follows the order in which qubits are clicked when composing the plaquette

For its implementation, I did not define a proper circuit class but have a simple function creating the ASCII art.

The automatically-generated circuit should be considered a starting point that the user can modify via the GUI.
Ideally, one wants the option of adding gates and moving them around.

Comments on the differences with the original frontend

• instead of qubits, the initial white circles are "positions" where the qubits may be added
• clicking a position adds a qubits there
• when a plaquette is created, qubits are added to it
• instead of dragging the plaquette around, I opted for a button to move it to predefined areas
• the plaquette's qubits are moved accordingly, thus freeing the option to add new qubits in the plaquette-building area for the next plaquette

@giangiac I think your work here is also addressing #46, which is essential to the main app, on top of having this educational tool for newcomers. Would you be able to spin off the circuit builder into a separate branch, and open a pull request for that specific issue?

@giangiac I think your work here is also addressing #46, which is essential to the main app, on top of having this educational tool for newcomers. Would you be able to spin off the circuit builder into a separate branch, and open a pull request for that specific issue?

Sam, I'll create a separate PR with the relevant code.

hi @giangiac and @smburdick I looked at your step-by-step branch and it's great! thank you @giangiac. I'm thinking of getting started with the connection between frontend and backend. Do you want me to wait until the new pr is made?

hi @giangiac and @smburdick I looked at your step-by-step branch and it's great! thank you @giangiac. I'm thinking of getting started with the connection between frontend and backend. Do you want me to wait until the new pr is made?

@rryoung98 Are you referring to #38?

hi @giangiac and @smburdick I looked at your step-by-step branch and it's great! thank you @giangiac. I'm thinking of getting started with the connection between frontend and backend. Do you want me to wait until the new pr is made?

Thanks, @rryoung98!
I have no clue how to connect the JS frontend with the Python backend. One "cheap" option is that the backend simply parses the .txt file with the library of plaquettes/circuits and take over from there. Effectively, this means two separate "programs/apps" that just agree on the output/input file format.

Is there a way to have a deeper integration?
How do you envision that?

An idea (not sure how realistic) may be having multiple "tabs" in the webapp. The first tab being the frontend, then the user can switch to other tabs for the template creation, etc etc. The code enabling the frontend functionalities (and thus the other tabs) is in Python, so I am not sure how/if that works.

hi @giangiac and @smburdick I looked at your step-by-step branch and it's great! thank you @giangiac. I'm thinking of getting started with the connection between frontend and backend. Do you want me to wait until the new pr is made?

Thanks, @rryoung98! I have no clue how to connect the JS frontend with the Python backend. One "cheap" option is that the backend simply parses the .txt file with the library of plaquettes/circuits and take over from there. Effectively, this means two separate "programs/apps" that just agree on the output/input file format.

Is there a way to have a deeper integration? How do you envision that?

An idea (not sure how realistic) may be having multiple "tabs" in the webapp. The first tab being the frontend, then the user can switch to other tabs for the template creation, etc etc. The code enabling the frontend functionalities (and thus the other tabs) is in Python, so I am not sure how/if that works.

@giangiac You're spot on, actually -- the frontend and backend communicate via REST APIs, using a predetermined JSON schema.

Your multi-tab idea was sketched up in one of our design files in the shared Gdrive, but I don't think we've looked into those as a group lateley.

Yes, it's going to be just rest apis with json (we will need to tweak your ascii circuits into something easier to parse like qasm).

Marking this as closed -- @giangiac