GSoC’24 CircuitVerse | Week 4–5 Report

Aryanndwivedi
2 min readJun 30, 2024

--

GSoC X CircuitVerse

Over the past two weeks, I’ve encountered and tackled several challenges while working on the Vue simulator and project versioning system for CircuitVerse. After discussing with Pulkit, Ruturaj, and Prerna, most of these issues have been resolved. However, these two weeks were heavily focused on experimenting, debugging, and exploring various ways to understand how the build process works.

Challenges I Faced

First Challenge (Vite configuration array)

During the build process of the Vue simulator through the vite.config.ts file, I initially used environment variables. However, after discussing with my mentors, I learned that this approach is not considered best practice. Instead, I should create an array storing all the versions and then build each version iteratively.

The problem arises because Vite expects a single configuration object, but our vite.config.ts file exports an array of configurations, which Vite's CLI cannot process correctly.

Approach to Solving the First Challenge

I’m currently working on creating two separate vite.config files and will use a bash script to execute both for building the versions.

Second Challenge (Dynamic Vue injection)

The index.html file serves as the initial entry point for the Vue application when it is loaded in a web browser. It contains:

<script type="module" src="/src/main.ts"></script>

This line points to the main.ts file where the actual Vue application is configured and initialized, injecting the Vue instance into the index.html file. With two versions (v0 and v1), we cannot inject both instances simultaneously in a single file. Instead, we need to inject the appropriate version dynamically based on the query parameter.

Approach to Solving the Second Challenge

To solve this, I created a directory vueversion/main.ts that index.html points to, and this directory injects the Vue instance according to the query parameter.

Storing the Version in the Circuit Database

Additionally, I added a new column (version) to the projects schema, setting the default version to v0.

To add a new column in the schema, I ran in my terminal:

rails generate migration AddVersionToProjects version:string

The migration file looked like this:

class AddVersionToProjects < ActiveRecord::Migration[7.0]
def change
add_column :projects, :version, :string, default: "v0", null: false
end
end

Then, I executed the migration with:

rails db:migratesh

Work Started This Week

Hotswapping: For hotswapping, I plan to take the version from the query parameter and serve the appropriate version accordingly. If a project is created in one version (e.g., v1), loading another version (e.g., v0) will result in an error. The application will then automatically switch to the specific version of the project.

--

--

No responses yet