Yuqiang/hack the victory modal for exam #7846
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughThe changes in this pull request involve updates to several components related to exam handling and user interface rendering. Key modifications include enhancements to the visibility logic for the home link in the control bar, the introduction of local storage management for exams, and updates to conditional rendering in the victory modal based on the exam context. These changes aim to improve the user experience during exams by ensuring appropriate UI elements are displayed based on the user's current state. Changes
Assessment against linked issues
Possibly related PRs
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint (1.23.1)
warning eslint@8.57.1: This version is no longer supported. Please see https://eslint.org/version-support for other options. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (9)
app/templates/play/level/control-bar-view.pug (2)
3-4: Consider consolidating level-specific logicThe condition
['resource-tycoon'].indexOf(view.level.get('slug'))could be simplified and potentially moved to a configuration file or constant.Consider applying this change:
- if (['resource-tycoon'].indexOf(view.level.get('slug')) != -1 || view.inExam) + const LEVELS_WITHOUT_HOME_LINK = ['resource-tycoon'] + if (LEVELS_WITHOUT_HOME_LINK.includes(view.level.get('slug')) || view.inExam)
Line range hint
11-15: Consider implementing exam-specific navigation componentWhile hiding the home link during exams is a good start, the PR objectives mention redirecting users to the exam progress page. Consider extracting exam-specific navigation into a separate component for better maintainability.
Suggested approach:
- Create an
ExamNavigationComponentthat handles exam-specific routing- Use conditional rendering to switch between standard and exam navigation
- Add clear instructions for exam navigation as mentioned in the objectives
This would make it easier to:
- Manage exam-specific navigation logic in one place
- Add exam progress page redirection
- Include user instructions for exam navigation
app/views/exams/StartPage.vue (1)
Line range hint
128-159: Consider enhancing exam state management architecture.The current implementation mixes Vuex state with localStorage, which could lead to synchronization issues. Consider these architectural improvements:
- Implement a cleanup mechanism for localStorage when exam ends
- Add Vuex actions to handle localStorage operations
- Ensure state consistency between Vuex and localStorage
Consider creating a dedicated Vuex action for exam storage management:
// In your Vuex store actions: { async setupExamStorage ({ commit, state }, { exam, duration }) { try { await storage.save('exam', exam, duration) commit('SET_EXAM_STORAGE_STATUS', true) return true } catch (error) { console.error('Failed to setup exam storage:', error) return false } }, async cleanupExamStorage ({ commit }) { await storage.remove('exam') commit('SET_EXAM_STORAGE_STATUS', false) } }This would provide better control over the exam lifecycle and state management.
app/views/play/level/ControlBarView.coffee (1)
49-52: Consider centralizing exam state management.The current implementation manages exam state directly in the view. Consider creating a dedicated exam state manager to:
- Centralize exam-related logic
- Provide consistent storage management
- Handle exam lifecycle events (start, end, cleanup)
- Implement proper error boundaries
Example structure:
# app/managers/ExamStateManager.coffee class ExamStateManager @STORAGE_KEY: 'coderabbit:exam' constructor: -> @examState = null startExam: (examData) -> storage.save(@constructor.STORAGE_KEY, examData) @examState = examData isInExam: (levelSlug) -> return false unless @examState?.problems? # ... level checking logic endExam: -> storage.remove(@constructor.STORAGE_KEY) @examState = nullWould you like me to create a GitHub issue to track this refactoring task?
app/views/play/level/modal/CourseVictoryComponent.vue (2)
103-108: Consider consistent button styling for exam continuationThe "continue exam" button uses different styling classes (
btn-success btn-grow) compared to other navigation buttons in the modal. Consider using consistent styling to maintain UI coherence.- a.btn.btn-illustrated.btn-success.btn-grow.btn-block.btn-lg.text-uppercase( + a.btn.btn-illustrated.btn-success.btn-glow.btn-block.btn-lg.text-uppercase(
103-108: Add instructional text for exam navigationThe PR objectives mention adding clear instructions for exam navigation. Consider adding helpful text to guide users:
.row(v-else) .col-sm-12.text-uppercase + .well.well-sm.well-parchment.mb-3 + p.text-center {{ $t('exams.navigation_instructions') }} a.btn.btn-illustrated.btn-success.btn-grow.btn-block.btn-lg.text-uppercase( @click="onReturnExam", )app/views/play/level/modal/CourseVictoryModal.js (3)
132-134: Add documentation for achievement filtering logicWhile the code changes improve safety and readability, the filtering logic for AI difficulty achievements could benefit from more detailed documentation.
Consider adding a more descriptive comment:
- this.achievements.models = _.filter(this.achievements.models, m => m.get('query')?.ladderAchievementDifficulty) // Don't show higher AI difficulty achievements + // Filter out achievements related to higher AI difficulty levels to keep the victory modal focused on core accomplishments + this.achievements.models = _.filter(this.achievements.models, m => m.get('query')?.ladderAchievementDifficulty)
239-242: Consider adding type checking for stats calculationThe optional chaining improves null safety, but consider adding explicit type checking for more robust error handling.
- stats: this.classroom?.statsForSessions(this.levelSessions, this.course.id), + stats: this.classroom && this.levelSessions ? this.classroom.statsForSessions(this.levelSessions, this.course.id) : null,
Line range hint
1-350: Consider implementing exam-specific error boundaryWhile the changes effectively implement exam victory modal requirements, consider adding an exam-specific error boundary to handle potential issues gracefully during exam navigation and state transitions.
This could include:
- Dedicated error states for exam-specific scenarios
- Fallback navigation paths for exam context
- Clear user messaging for exam-related errors
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
app/templates/play/level/control-bar-view.pug(1 hunks)app/views/exams/StartPage.vue(3 hunks)app/views/play/level/ControlBarView.coffee(1 hunks)app/views/play/level/modal/CourseVictoryComponent.vue(6 hunks)app/views/play/level/modal/CourseVictoryModal.js(5 hunks)
🔇 Additional comments (9)
app/templates/play/level/control-bar-view.pug (2)
1-4: Verify integration with victory modal
Since the PR title mentions "hack the victory modal for exam", we should verify that hiding the home link is coordinated with victory modal changes.
Let's check the integration:
✅ Verification successful
Integration with victory modal is properly coordinated
The changes in the control bar's home link visibility are well-coordinated with the victory modal behavior:
- The
CourseVictoryComponentchecks forinExamstate using the same logic as the control bar - The victory modal already handles exam state by conditionally hiding various UI elements like:
- Replay level button
- Challenge button
- Back to map button
- Level completion information
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check victory modal integration with exam state
# Find victory modal template/component
fd -e vue -e pug -e coffee victory
# Check exam-related logic in victory components
rg -A 5 'inExam.*victory'
Length of output: 616
Script:
#!/bin/bash
# Let's check the victory modal templates for exam-related logic
cat app/templates/play/level/modal/victory.pug
cat app/templates/play/level/modal/course-victory-modal.pug
# Also check for any exam-related logic in the codebase
rg -l "inExam.*modal"
Length of output: 2354
Script:
#!/bin/bash
# Let's check for exam-related state handling in the codebase
rg -A 5 "inExam" app/views/play/level/
rg -A 5 "exam.*modal" app/views/play/level/
# Also check for any victory modal related components
ast-grep --pattern 'class $_ extends $_ {
$$$
inExam
$$$
}'
Length of output: 3590
3-4: Verify exam state initialization
The condition correctly hides the home link during exams, which aligns with the PR objective to prevent navigation confusion. However, we should verify that view.inExam is properly initialized.
Let's verify the exam state initialization:
✅ Verification successful
Let me generate additional scripts to verify the exam state initialization:
Exam state initialization is properly handled
The exam state (inExam) is correctly initialized and managed:
- In
ControlBarView.coffee, it's set based on exam problems:@inExam = _.any exam.problems, (courseLevels) => - In
CourseVictoryComponent.vue, it's retrieved from storage:exam = storage.load('exam', true) - The condition in
control-bar-view.pugcorrectly uses this state to hide navigation elements during exams
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check how inExam is initialized and used across components
# Find where inExam is set/initialized
ast-grep --pattern 'inExam = $_'
# Find related exam state management
rg -A 5 'localStorage.*exam'
Length of output: 115431
Script:
#!/bin/bash
# Search for exam state initialization and usage
rg -A 5 "inExam" app/
# Find related exam state management in view files
rg -A 5 "view.inExam" app/
# Check for exam state in control bar view
rg -A 5 "inExam" app/templates/play/level/control-bar-view.pug
Length of output: 4599
app/views/exams/StartPage.vue (2)
63-63: LGTM! Verify storage module availability.
The storage import is correctly placed and follows Vue 2.x patterns.
✅ Verification successful
Let me verify the contents of the storage module to ensure it exports the expected functionality.
Storage module import is valid and provides required functionality
The storage module exists at the correct path and exports the necessary localStorage management functions (load, save, remove) that would be suitable for exam state management. The implementation includes proper error handling and flexible caching options.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the storage module exists and exports expected methods
fd -e js -e ts "storage.js|storage.ts" app/core/
Length of output: 70
Script:
#!/bin/bash
# Check the contents of the storage module
cat app/core/storage.js
Length of output: 1521
Line range hint 1-195: Verify exam state persistence across navigation.
While the implementation aligns with the PR objectives, we should verify the exam state persistence works correctly across different navigation scenarios.
✅ Verification successful
Exam state persistence is properly implemented and verified.
The implementation shows a robust exam state management system with:
-
Proper storage handling in StartPage.vue:
- Saves exam state to localStorage with duration limit
- Handles timer and navigation based on exam state
- Manages exam continuation for existing users
-
Clean state management through Vuex store (exams.js):
- Centralized state management for exam and user exam data
- Proper API integration for exam operations
- Clear separation of mutations and actions
-
Proper cleanup and navigation:
- Auto-navigation to end page on timeout
- Proper state cleanup on submission
- Handles archived exam states
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all exam-related navigation handling
rg -l "router.navigate.*exam" --type vue --type coffee
# Check for potential race conditions in exam state management
rg "storage.(save|remove).*exam" --type vue --type coffee
# Verify cleanup of exam storage
rg "exam.*submitted" --type vue --type coffee
Length of output: 248
Script:
#!/bin/bash
# Search for all exam-related navigation handling
rg -l "router.navigate.*exam"
# Check for potential race conditions in exam state management
rg "storage\.(save|remove).*exam"
# Verify cleanup of exam storage
rg "exam.*submitted"
# Check for other files using storage for exam state
fd -e vue -e js -e coffee | xargs grep -l "storage"
Length of output: 3807
Script:
#!/bin/bash
# Check exam state management in core storage
cat app/core/storage.js
# Check exam-related state cleanup and navigation in progress/end views
fd "Progress|End" -e vue -t f | xargs cat
# Look for exam state management in Vuex store
fd "exams" -e js | xargs cat
Length of output: 51750
app/views/play/level/ControlBarView.coffee (1)
49-52: Verify template implementation for exam navigation.
The PR objectives mention hiding "back to map" and "next level" options during exams, but the template changes aren't included in this review. Please ensure that control-bar-view.pug properly utilizes the @inExam flag to hide these navigation elements.
Let's verify the template implementation:
✅ Verification successful
Let me check the template content to verify how the navigation elements are controlled.
Template correctly implements exam navigation restrictions
The template already properly handles the exam mode navigation restrictions:
- The
includeHomeLinkvariable is set tofalsewhenview.inExamis true - When
includeHomeLinkis false, both the.levels-link-area(back to map) and the#next-game-buttonare not rendered
The changes to set @inExam in the view are correctly integrated with the template's conditional rendering logic to hide navigation elements during exams.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check template implementation for exam navigation
# Look for the template file and its usage of @inExam
# Find the template file
fd -e pug "control-bar-view"
# Check for navigation-related conditionals in the template
rg -A 5 "next-game-button|levels-link-area|home a"
Length of output: 30035
Script:
#!/bin/bash
# Check the template content to see how navigation elements are controlled
cat app/templates/play/level/control-bar-view.pug
# Check if there are any conditionals in the view that control these elements
rg -A 3 "render|@inExam" app/views/play/level/ControlBarView.coffee
Length of output: 2652
app/views/play/level/modal/CourseVictoryModal.js (4)
97-104: LGTM: Improved tracking and goal state handling
The changes enhance tracking by including levelSlug and improve goal state handling with modern JavaScript features (optional chaining).
183-183: LGTM: Added course instance context to progress view
The addition of courseInstanceID to progressView options ensures proper exam context handling.
Line range hint 65-74: LGTM: Session-aware next level fetching
The addition of sessionID to the API call parameters improves context awareness when fetching the next level, which aligns with the exam functionality requirements.
Let's verify the API endpoint handles the sessionID parameter correctly:
✅ Verification successful
LGTM: Session-aware next level fetching is properly implemented
The API endpoint correctly handles the sessionID parameter. When a courseInstanceID is present, it uses the session-aware endpoint /db/course_instance/${courseInstanceID}/levels/${levelOriginalID}/sessions/${sessionID}/next, which incorporates the session context for fetching the next level. The fallback endpoint for courses without instances is also properly implemented.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the API endpoint accepts sessionID parameter
rg -A 3 "fetchNextForCourse" .
Length of output: 1128
Script:
#!/bin/bash
# Let's check the API endpoint implementation to verify sessionID handling
ast-grep --pattern 'fetchNextForCourse ({ $$$, sessionID }, $_) {
$$$
}'
# Also check the API call construction
rg -B 2 -A 5 "url = " app/core/api/levels.js
Length of output: 1008
247-247: Verify store integration with CourseVictoryComponent
The addition of the store prop suggests state management integration. Ensure the component properly handles the store.
✅ Verification successful
Store integration is correctly implemented
The store integration in CourseVictoryComponent is properly implemented and used:
- The component accesses store state through
@$store.stateto get level and hero configuration data - The store prop is correctly passed from CourseVictoryModal to CourseVictoryComponent
- The store is used for reading state only, following Vue best practices
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check store usage in CourseVictoryComponent
ast-grep --pattern 'store.$$$' CourseVictoryComponent.vue
Length of output: 133
Script:
#!/bin/bash
# First, let's find the correct path for the component
fd CourseVictoryComponent
# Let's also check for store usage in the modal file we know about
rg -A 2 "store" app/views/play/level/modal/CourseVictoryModal.js
# Let's see the full content of the modal file to understand the store integration
cat app/views/play/level/modal/CourseVictoryModal.js
Length of output: 15205
Script:
#!/bin/bash
# Let's check the CourseVictoryComponent for store usage
cat app/views/play/level/modal/CourseVictoryComponent.vue
# Also check for any store-related imports or usage in the component
rg -A 2 "store" app/views/play/level/modal/CourseVictoryComponent.vue
Length of output: 14089
| this.setupLocalStorage() | ||
| this.loading = false | ||
| application.router.navigate(window.location.pathname.replace(/start$/, 'progress'), { trigger: true }) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve error handling flow in exam start process.
The storage setup and navigation sequence could be improved:
- Storage setup occurs after loading state is cleared
- Navigation proceeds without verifying storage success
Consider this improved flow:
- this.setupLocalStorage()
- this.loading = false
- application.router.navigate(window.location.pathname.replace(/start$/, 'progress'), { trigger: true })
+ if (!this.setupLocalStorage()) {
+ noty({
+ text: 'Failed to initialize exam storage',
+ type: 'error',
+ timeout: 5000,
+ })
+ this.loading = false
+ return
+ }
+ this.loading = false
+ application.router.navigate(window.location.pathname.replace(/start$/, 'progress'), { trigger: true })Committable suggestion skipped: line range outside the PR's diff.
app/views/exams/StartPage.vue
Outdated
| setupLocalStorage () { | ||
| storage.save('exam', this.exam, this.limitedDuration) | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add error handling and validation to storage setup.
The storage setup lacks error handling and validation of required data.
Consider this safer implementation:
setupLocalStorage () {
+ if (!this.exam) {
+ console.error('Cannot setup storage: exam data is missing')
+ return false
+ }
+ if (!this.limitedDuration) {
+ console.warn('Storage setup: No duration specified, using default')
+ }
storage.save('exam', this.exam, this.limitedDuration)
+ return true
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| setupLocalStorage () { | |
| storage.save('exam', this.exam, this.limitedDuration) | |
| }, | |
| setupLocalStorage () { | |
| if (!this.exam) { | |
| console.error('Cannot setup storage: exam data is missing') | |
| return false | |
| } | |
| if (!this.limitedDuration) { | |
| console.warn('Storage setup: No duration specified, using default') | |
| } | |
| storage.save('exam', this.exam, this.limitedDuration) | |
| return true | |
| }, |
| exam = storage.load('exam', true) | ||
| if exam | ||
| @inExam = _.any exam.problems, (courseLevels) => | ||
| _.find courseLevels.levels, { slug: @level.get('slug') } |
There was a problem hiding this comment.
💡 Codebase verification
🛠️ Refactor suggestion
Based on the search results, I can now provide a final response regarding the exam state management:
Consider using a dedicated exam state manager to handle exam storage lifecycle
The exam state management is currently handled directly in multiple components without proper cleanup:
ControlBarView.coffeeloads and checks exam stateCourseVictoryComponent.vuealso loads and checks exam state- No dedicated cleanup of exam storage is found in victory or completion flows
To improve reliability and maintainability:
-
Create a dedicated exam state manager class to handle:
- Loading/saving exam state with a prefixed key
- Proper cleanup on exam completion/exit
- Validation of exam data structure
- Single source of truth for exam state checks
-
Update the current direct storage access points to use the manager instead:
- exam = storage.load('exam', true)
+ examManager.getExamState()🔗 Analysis chain
Improve exam state management robustness and maintainability.
Several improvements could enhance the reliability of exam state management:
- Use a prefixed constant for the storage key to prevent conflicts
- Add data structure validation
- Implement proper cleanup of exam storage
- Simplify the nested lodash operations
Consider applying these changes:
- exam = storage.load('exam', true)
- if exam
- @inExam = _.any exam.problems, (courseLevels) =>
- _.find courseLevels.levels, { slug: @level.get('slug') }
+ STORAGE_KEYS = {
+ EXAM: 'coderabbit:exam'
+ }
+
+ exam = storage.load(STORAGE_KEYS.EXAM, true)
+ if exam?.problems?
+ currentSlug = @level.get('slug')
+ @inExam = exam.problems.some (courseLevels) =>
+ courseLevels.levels?.some (level) => level.slug is currentSlugLet's verify the exam storage cleanup:
Let me gather more information about exam-related storage usage to better understand the cleanup patterns.
Let me check the victory modal for exam-related storage handling and also search with correct file type patterns.
Let me try one more search to find exam-related storage handling:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if exam storage is properly cleaned up
# Look for storage cleanup code in the codebase
rg -A 5 "storage\.(remove|clear)"
ast-grep --pattern 'storage.$_(exam)'
Length of output: 1386
Script:
#!/bin/bash
# Search for exam-related storage operations and their context
rg -A 10 -B 5 "exam" --type coffee --type js | grep -v "example"
# Search for any exam cleanup patterns in victory-related files
fd -e coffee -e js victory -x rg -l "storage" {}
Length of output: 201
Script:
#!/bin/bash
# Search for exam-related code in victory modal
cat ./ozaria/site/views/play/level/modal/HeroVictoryModal.js
# Search with correct file extensions for exam-related storage
rg -t js -t coffeescript -A 10 -B 5 "exam.*storage"
# Look for exam state management in control bar and victory-related files
fd -e coffee -e js "Control|Victory" -x rg -l "exam" {}
Length of output: 149015
Script:
#!/bin/bash
# Search for exam storage usage and cleanup
rg -B 5 -A 10 "storage\.(load|save|remove).*exam" --type coffee --type js
# Look for exam state management in victory-related files
rg -B 5 -A 10 "exam" app/views/play/level/
Length of output: 28316
| onReturnExam: -> | ||
| window.close() |
There was a problem hiding this comment.
Enhance exam return behavior with fallback and analytics
The current implementation has several concerns:
window.close()may be blocked by browsers- Missing analytics tracking
- No fallback behavior
Consider this more robust implementation:
onReturnExam: ->
+ window.tracker?.trackEvent(
+ 'Play Level Victory Modal Return to Exam',
+ {
+ category: 'Students'
+ levelSlug: @level.slug
+ },
+ []
+ )
window.close()
+ # Fallback if window.close() is blocked
+ window.location.href = '/play/exam'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| onReturnExam: -> | |
| window.close() | |
| onReturnExam: -> | |
| window.tracker?.trackEvent( | |
| 'Play Level Victory Modal Return to Exam', | |
| { | |
| category: 'Students' | |
| levelSlug: @level.slug | |
| }, | |
| [] | |
| ) | |
| window.close() | |
| # Fallback if window.close() is blocked | |
| window.location.href = '/play/exam' |
| inExam: -> | ||
| exam = storage.load('exam', true) | ||
| return _.any exam.problems, (courseLevels) => | ||
| return _.find(courseLevels.levels, {slug: @level.slug}) | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add null checks and optimize exam state checking
The inExam computed property needs defensive programming and performance optimization:
- Missing null check for exam data
- Repeated array operations could impact performance
Consider this more robust implementation:
inExam: ->
exam = storage.load('exam', true)
- return _.any exam.problems, (courseLevels) =>
- return _.find(courseLevels.levels, {slug: @level.slug})
+ return exam?.problems?.some (courseLevels) =>
+ return courseLevels.levels?.some (level) =>
+ return level.slug is @level.slug📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| inExam: -> | |
| exam = storage.load('exam', true) | |
| return _.any exam.problems, (courseLevels) => | |
| return _.find(courseLevels.levels, {slug: @level.slug}) | |
| inExam: -> | |
| exam = storage.load('exam', true) | |
| return exam?.problems?.some (courseLevels) => | |
| return courseLevels.levels?.some (level) => | |
| return level.slug is @level.slug | |
| @@ -196,9 +202,16 @@ | |||
| nextLevelVideo: -> | |||
| if me.isStudent() and @course._id == utils.courseIDs.INTRODUCTION_TO_COMPUTER_SCIENCE and !me.showHeroAndInventoryModalsToStudents() | |||
| return utils.videoLevels[@nextLevel.original] | |||
| inExam: -> | |||
| exam = storage.load('exam', true) | |||
| return _.any exam.problems, (courseLevels) => | |||
There was a problem hiding this comment.
let's just return true instead of checking levels during the exam. We don't need to worry about mto students playing other things during the exam
There was a problem hiding this comment.
i don't think this takes too many time. (like only 10 loops or 20 loops). as it's simple, we can return good checking
| } | ||
| methods: { | ||
| marked | ||
| onReturnExam: -> | ||
| window.close() |
There was a problem hiding this comment.
we could actually open the exam URL of progress, right? If it's possible, lets' do that.
There was a problem hiding this comment.
we can while, i don't want to open too many pages. or you think we can open the level link in current tab and make this button return to progress page?
fix ENG-1430
i simply set the storage time to be exam duration. i think that should work good
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Refactor