Init: Restricted Circuit Elements

Task.new

This weeks task on the list was - restricting circuit elements in assignment submissions (course instructors can get very brutal at times!). This task was trickier than the ones I worked on in the initial weeks. I had to go through a lot of javascript code to get a deep understanding of how things worked inside the simulator.

For the new folks! This is what the simulator looks like! Currently there are 56 independent elements that can be used. Shout out to my mentors - satu0king, tachyons and vik-y for the awesome work!

Before working on this task, these elements were entirely handled and dealt with on the front-end. In order to restrict the usage of these elements, I had to figure out a way to make them available to the back-end and hence came into the picture, the CircuitElement model. This model stores the name and image associated with the element. Now, it was necessary to associate these to the assignments. This was achieved through the following relationships -

class CircuitElement < ApplicationRecord
  has_and_belongs_to_many :assignments
end

class Assignment < ApplicationRecord
  has_and_belongs_to_many :circuit_elements
  accepts_nested_attributes_for :circuit_elements
end

How the modules and elements come into play to produce the simulations that one sees on the front-end, are very well explained in this wiki. The files that were most relevant to this task were - data.js, listeners.js and logix.js.

@project.data.inspect

As obvious as the property’s name makes it(:P), all information regarding a circuit is stored in the back-end in this text key. Every @project has a data key. Some important attributes in data are - layout, projectName, scopes etc. scopes is where the information for all elements used in the simulation is stored. Hence, it seemed natural to have the information of restrictedCircuitElementsUsed in the scope, to be stored here.

This is what a general scope looks like -

{
	...
	"layout"=>{"width"=>100, "height"=>40, "title_x"=>50, "title_y"=>13, "titleEnabled"=>true},
	# list of all nodes
	"allNodes"=> [] 
	"id"=>75214734864,
	# circuit name
	"name"=>"Main", 
	# an array of the circuit elements of type HexDisplay being used inside the scope. 
	"HexDisplay"=> [{<circuit-element-info>}]
	"labelDirection"=>"DOWN", "propagationDelay"=>100, "customData"=>{"nodes"=>{"inp1"=>4}}}],
	# A list of all the restricted elements being used in the scope
	"restrictedCircuitElementsUsed"=>["HexDisplay"] 
 	...
 }

data.js is the file responsible for producing this data and sending this to the backend whenever a save is requested by the user. It was here where I had to make changes to incorporate the restrictedCircuitElementsUsed key. For adding warning for whenever a user used a restricted element, I added listener implementations in logix.js. These were initalized with their respective circuit elements in listeners.js. So the net flow of looked like -

1. Backend renders simulator/edit.html.erb which initializes restrictedElements for the project.

2. listeners.js initializes the functions for showing and updating usage warnings, and also to update the scope information about the currently used restricted elements.

3. On save, data.js handles parsing the scope information for producing the data to be stored in backend and sends request to simualtor_constoller#update.
   
   This flow works fine if we have blind faith in the students of the group (but ofcourse not!). So a back-end check is also required while saving the data to ensure there is no tampering with the restrictedCircuitElementsUsed key. Hence came into the picture, a sanitize_data helper and the 4th step in the flow:

4. While saving data check data from frontend and sanitize it to ensure restrictedCircuitElementsUsed is populated correctly.

To top everything off, I added a mean looking “Restricted elements used” help box in the circuit preview so that it is also visible to the course instructor while grading the circuit.

Week.next

There is still some finishing required before this work gets merged #390. In the upcoming week I’ll be primarily focusing on getting this PR reviewed and work on improvements. Meanwhile the previous PR for grading feature is also left to be given a green flag. I’ll aim to get both features reviewed and merged. And then …

I’ll be back.