fix: resolve performance issues with O(n*m) lookups and redundant computations

[jeremystucki]

Summary

Replaces O(n) array lookups with O(1) Map/Set equivalents across the store and components, eliminates redundant computations, and fixes a pre-existing null-safety bug.

Store (src/helpers/store.ts)

• Added moduleMap getter — a Map<string, Module> keyed by ID, replacing O(n) Array.find calls throughout
• Added allPlannedModuleIdsSet getter — a Set<string> of all planned module IDs, replacing O(n) Array.includes calls throughout
• Removed unused modulesByIds getter
• Fixed allPlannedModuleIds filter to use a type-guard (.filter((id): id is string => !!id)) so the array and derived Set are truly string[]
• enrichedSemesters, enrichedCategories, enrichedFocuses: use moduleMap.get() for O(1) lookups and use the Vuex state parameter instead of accessing store.state directly
• enrichedFocuses: fixed null-safety bug — successorModuleId can be null/undefined, now guarded before being passed to Set.has()
• getPlannedEcts / getEarnedEcts: accept enrichedSemesters as a parameter instead of re-reading it from store.getters, avoiding redundant recomputation

Components

• GraphModule.vue: recommendedModules and dependentModules use moduleMap.get() and allPlannedModuleIdsSet.has()
• GraphModuleHightlight.vue, ModuleSearchListItem.vue: isPlanned / moduleIsInPlan use allPlannedModuleIdsSet.has()
• ModuleSearch.vue:
  • categoryFilterData, ectsFilterData, semesterFilterData moved from methods to computed properties to enable Vue caching
  • semesterFilterData backed by a module-level constant (data never changes)
  • ectsFilterData deduplication changed from O(n²) indexOf to O(n) new Set()
  • isOneModuleAvailable converted from a deep-watched data property to a computed using some()
  • Three sequential module filter passes (ECTS, semester, query) collapsed into one
  • modulesInGroupIds uses a Set for O(1) membership check

Composable / View

• useGraphView.ts: computeLayout builds a local Set from allPlannedModuleIds for the filter instead of O(n) Array.includes
• Home.vue: replaced setTimeout(() => {}, 0) with this.$nextTick() for correct Vue timing semantics

[Copilot]

Pull request overview

This PR targets performance bottlenecks caused by repeated linear lookups (Array.find / Array.includes) and redundant recomputation, primarily by introducing Map/Set-backed access patterns and consolidating filtering logic.

Changes:

• Added moduleMap and allPlannedModuleIdsSet Vuex getters and refactored multiple derived getters to use them.
• Updated several components/composables to use Set.has() / Map.get() instead of includes() / find().
• Refactored ModuleSearch filtering and moved filter data builders to computed properties to reduce redundant work.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/views/Home.vue	Uses $nextTick instead of setTimeout(…, 0) before reading plan data from URL after route changes.
src/helpers/store.ts	Introduces moduleMap/allPlannedModuleIdsSet, updates enriched getters and ECTS computations to reuse enriched semesters.
src/composables/useGraphView.ts	Uses a Set for planned-module membership checks during layout computation.
src/components/ModuleSearchListItem.vue	Switches plan-membership check from includes to Set.has.
src/components/ModuleSearch.vue	Avoids calling filter-data builders from the template, simplifies filtering, and uses a Set for “modules in groups” checks.
src/components/GraphModuleHightlight.vue	Switches planned-state check from includes to Set.has.
src/components/GraphModule.vue	Switches recommended/dependent module lookups to Map.get and planned checks to Set.has.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

@jeremystucki I've opened a new pull request, #130, to work on those changes. Once the pull request is ready, I'll request review from you.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (2)

src/helpers/store.ts:59

• In enrichedSemesters, semester.moduleIds.map(id => map.get(id)).filter(f => f) removes undefined at runtime but doesn’t narrow the type, even though Semester.modules is declared as Module[]. Prefer a type-guard filter ((m): m is Module => !!m) to keep the getter output consistent with the model types.

    enrichedSemesters: (state, getters) => {
      const map = getters.moduleMap as Map<string, Module>;
      return state.semesters.map(semester => ({
        ...semester,
        modules: semester.moduleIds.map(id => map.get(id)).filter(f => f),
      }));

src/helpers/store.ts:70

• In enrichedCategories, modules: category.moduleIds.map(id => map.get(id)).filter(f => f) has the same issue as enrichedSemesters: runtime filtering doesn’t type-narrow to Module[] even though Category.modules is declared as Module[]. Use a type-guard filter to keep types consistent and avoid downstream casts.

    enrichedCategories: (state, getters) => {
      const map = getters.moduleMap as Map<string, Module>;
      const enrichedSemesters = getters.enrichedSemesters;
      return state.categories.map(category => ({
        ...category,
        earnedEcts: getEarnedEcts(category, enrichedSemesters),
        plannedEcts: getPlannedEcts(category, enrichedSemesters),
        colorClass: getColorClassForCategoryId(category.id),
        modules: category.moduleIds.map(id => map.get(id)).filter(f => f),
      }));

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/helpers/store.ts:66

• enrichedCategories sets modules with .map(...).filter(f => f), which doesn’t type-narrow and can leave modules typed as (Module | undefined)[]. Use a type-guard filter ((m): m is Module => !!m) to keep the getter’s return shape consistent with Category.modules: Module[] and avoid the need for later type assertions.

        ...category,
        earnedEcts: getEarnedEcts(category, enrichedSemesters),
        plannedEcts: getPlannedEcts(category, enrichedSemesters),
        colorClass: getColorClassForCategoryId(category.id),
        modules: category.moduleIds.map(id => map.get(id)).filter(f => f),
      }));

src/helpers/store.ts:74

• allModulesForFocus is created with .filter(f => f) as Module[]. The as Module[] assertion is hiding the fact that the filter isn’t a type guard. Replace it with a proper type-guard filter so this is actually Module[] without an unsafe cast.

      const numberOfModulesRequiredToGetFocus = 8;
      return state.focuses.map(focus => {
        const allModulesForFocus = focus.moduleIds.map(id => map.get(id)).filter(f => f) as Module[];
        return {

src/helpers/store.ts:92

• availableModules finishes with .map(id => map.get(id)).filter(f => f), which again isn’t a type-guard and leaves the resulting array typed as (Module | undefined)[]. Use a type-guard filter ((m): m is Module => !!m) so availableModules is unambiguously Module[].

            })
            .map(id => map.get(id))
            .filter(f => f),

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

[Untersander]

LGTM, tested it and it is more performant.