Greasy Fork is available in English.
听说你抢不到课
谢谢你的回复！现在的默认时延是375毫秒，略微低于你说的1秒不超过3条。延时的影响忘记解除，确实是一个很恶劣的问题，我在2.x版本中对其进行了修复。
版本3最大的优势是，将选课功能嵌入到了学校的选课系统中，可以简化手动复制课程代码的繁琐性。
至于“禁用了延时遍历前的再次点击操作，冲突的点击操作是否被记忆”，目前来看，如果你在第一次遍历过程中进行点击，那么会尝试终止上一次遍历，然后立刻开启下一次遍历。在这两个事件发生之间的点击会被禁止。从这个角度看，冲突的点击操作不会被记忆，而是立刻结束上一次迭代。
这里有些逻辑可以进一步完善，比如在遍历过程中，禁用输入框，添加和删除功能，并提供一个禁用按钮等，但复杂的逻辑可能引入更多的问题，我认为没有必要。
1.0.3是相比原版修复了https未适配的问题，后面的2.x是有bug的，课程添加到列表里都没显示。从2.x版本起引入了延时功能，然而延时的影响忘记解除导致不能发出再次请求。3.0.1版本修复了延时的影响问题，相比1.0.3带来的新特性是列表里的选项自上至下以475ms延时逐个发出请求。3.0.1版本的更新禁止了延时遍历结束前的再次点击操作，但是冲突的点击操作是否被记忆？就是我的第二次点击失效了，在延时遍历结束后是否会自动帮我进行第二次遍历？另外，有人提出，实际的请求限制约是一秒钟不超过3条，认为可以三条请求一次性发出，然后延时一秒后再进行第二次同时请求，不过这样导致的问题就是如果遇到手快情况，三个选项均会失败。对于我目前而言，我更偏向考虑使用1.0.3版本，更加传统保守，问题是可能会因为连点导致请求全部失败。
你提到了新的请求发起方式，即1秒3个，这个思路很有趣，我试一下。
将选课功能嵌入到了学校的选课系统中，可以简化手动复制课程代码的繁琐性。这一点我一开始没有发现，原因是我当时打开的是通选课页面。当我切换到其他页面的时候，惊喜看到了“添加”按钮。换句话说，我刚好发现了通选课未适配的问题，推测原因是通选课的显示方式和其他板块的折叠形式不太一样，不知可否修复？另外，根据您上面的解释，第二次点击会直接杀死未完成的遍历，而每一次遍历都会从第一个开始。也就意味着在连点状态下，很可能被遍历的永远是第一或前两条课程，这样在实用性上可能导致较为严重的问题。况且，杀死前一次遍历并不关心杀死的前一次请求过后间隔多少秒，直接开始了下一次遍历，可能导致请求过多问题。依我的观点，在第二次点击时如果第一次遍历尚未执行完，将记忆第二次点击，并自动等到第一次遍历结束后进行执行第二次遍历。然而如果数次点击被记忆后延迟执行，很可能导致并不需要点击但依然未结束所有点击，可能影响其他课程的选择。因此建议新增终止按钮。总结来说，就是如果遇到前一次遍历未执行完，则等结束后再进行下一次遍历，此外新增遍历终止按钮用于跳出遍历模式。
一秒请求三个的最大的问题就是，在手快提前点场景下导致三个均无效，然后下一次发出请求已经要一秒后了，可能导致一个都选不上。而原先的遍历方案，纵使手快第一个无效，后面两个依然能够有效请求。（虽然按照475ms延时逻辑，第三个已经到1s以后，上的可能性已经大大降低了，但至少在手快早点弄情形下，中间某个请求一定能够不出问题）另一位学长的经过自己的研究后，他的意见是0.8秒内的请求个数不能超过三个，认为0.8s/3个是最最极限。
将选课功能嵌入到了学校的选课系统中，可以简化手动复制课程代码的繁琐性。这一点我一开始没有发现，原因是我当时打开的是通选课页面。当我切换到其他页面的时候，惊喜看到了“添加”按钮。换句话说，我刚好发现了通选课未适配的问题，推测原因是通选课的显示方式和其他板块的折叠形式不太一样，不知可否修复？另外，根据您上面的解释，第二次点击会直接杀死未完成的遍历，而每一次遍历都会从第一个开始。也就意味着在连点状态下，很可能被遍历的永远是第一或前两条课程，这样在实用性上可能导致较为严重的问题。况且，杀死前一次遍历并不关心杀死的前一次请求过后间隔多少秒，直接开始了下一次遍历，可能导致请求过多问题。依我的观点，在第二次点击时如果第一次遍历尚未执行完，将记忆第二次点击，并自动等到第一次遍历结束后进行执行第二次遍历。然而如果数次点击被记忆后延迟执行，很可能导致并不需要点击但依然未结束所有点击，可能影响其他课程的选择。因此建议新增终止按钮。总结来说，就是如果遇到前一次遍历未执行完，则等结束后再进行下一次遍历，此外新增遍历终止按钮用于跳出遍历模式。
这里的“杀死”可能和你想的不太一样。“杀死”不是“立即”实现的。
一个进程运行时，会将isRunning设为true，同时shouldStop默认为false。
上一个进程正在运行，对应的状态是状态A：isRunning=true, shouldStop=false
此时发起下一个进程，对应的状态是状态B：isRunning=true, shouldStop=true
上一个进程被终止，对应的状态是状态C：isRunning=false, shouldStop=false
而isRunning=false, shouldStop=true状态非法，不可能出现。
初始为状态C，点击按钮会变成状态A，再次点击会变成状态B，上一个进程收到停止请求后，变回C，收到前，禁用点击事件。
经过实际测试，连续快速点击2-5下的结果确实是第一个选项被请求了相应次数，但是从第二个往后的选项仅被请求了一次，意味着如果频繁点击，最终被反复请求的始终只有子一个选项，而后面的选项反而被连点耽误导致选不上，这样应该并不是用户想要的结果吧🤔🤔
将选课功能嵌入到了学校的选课系统中，可以简化手动复制课程代码的繁琐性。这一点我一开始没有发现，原因是我当时打开的是通选课页面。当我切换到其他页面的时候，惊喜看到了“添加”按钮。换句话说，我刚好发现了通选课未适配的问题，推测原因是通选课的显示方式和其他板块的折叠形式不太一样，不知可否修复？另外，根据您上面的解释，第二次点击会直接杀死未完成的遍历，而每一次遍历都会从第一个开始。也就意味着在连点状态下，很可能被遍历的永远是第一或前两条课程，这样在实用性上可能导致较为严重的问题。况且，杀死前一次遍历并不关心杀死的前一次请求过后间隔多少秒，直接开始了下一次遍历，可能导致请求过多问题。依我的观点，在第二次点击时如果第一次遍历尚未执行完，将记忆第二次点击，并自动等到第一次遍历结束后进行执行第二次遍历。然而如果数次点击被记忆后延迟执行，很可能导致并不需要点击但依然未结束所有点击，可能影响其他课程的选择。因此建议新增终止按钮。总结来说，就是如果遇到前一次遍历未执行完，则等结束后再进行下一次遍历，此外新增遍历终止按钮用于跳出遍历模式。
这里的“杀死”可能和你想的不太一样。“杀死”不是“立即”实现的。
一个进程运行时，会将isRunning设为true，同时shouldStop默认为false。
上一个进程正在运行，对应的状态是状态A：isRunning=true, shouldStop=false
此时发起下一个进程，对应的状态是状态B：isRunning=true, shouldStop=true
上一个进程被终止，对应的状态是状态C：isRunning=false, shouldStop=false
而isRunning=false, shouldStop=true状态非法，不可能出现。
初始为状态C，点击按钮会变成状态A，再次点击会变成状态B，上一个进程收到停止请求后，变回C，收到前，禁用点击事件。
而且，在3.0.1版本中，enroll函数中有这样一段逻辑：
if (res.data.code === 100) {
delete enrollDict[key]; // 移除成功的课程
key_list = Object.keys(enrollDict).filter(
(key) =>
enrollDict[key].courseBatch === grablessonsVue.lcParam.currentBatch.code
);
} else {
index++;
}
换句话说，成功抢选的课程会从列表中移除。所以，即使“每一次遍历都会从第一个开始”，也不会出现“被遍历的永远是第一或前两条课程”。
好的，成功抢选的可以被移除，只是我的测试场景是未开始选课状态，因此在正式选课的时候就不会再出现这样的问题了，非常感谢！
好的，成功抢选的可以被移除，只是我的测试场景是未开始选课状态，因此在正式选课的时候就不会再出现这样的问题了，非常感谢！
这一段代码：
// if (res.data.code === 100) {
if (true) {
delete enrollDict[key]; // 移除成功的课程
methods.saveCourse();
window.Components.reloadList();
key_list = Object.keys(enrollDict).filter(
(key) =>
enrollDict[key].courseBatch ===
grablessonsVue.lcParam.currentBatch.code
);
} else {
index++;
}
可以模拟每次选课都成功的状态。如果不放心的话，可以试一试。
好的，成功抢选的可以被移除，只是我的测试场景是未开始选课状态，因此在正式选课的时候就不会再出现这样的问题了，非常感谢！
那我就暂时不设计“终止按钮”了，这可能会引入许多新问题。终止按钮会破坏原来的状态转移模型，从而不得不引入“按钮禁用”，但逻辑又太复杂...我先看能否解决通选课的问题。
咦，课程后面的“更多”功能不知哪个版本开始完善了哈哈哈
好的，成功抢选的可以被移除，只是我的测试场景是未开始选课状态，因此在正式选课的时候就不会再出现这样的问题了，非常感谢！
这一段代码：
// if (res.data.code === 100) { if (true) { delete enrollDict[key]; // 移除成功的课程 methods.saveCourse(); window.Components.reloadList(); key_list = Object.keys(enrollDict).filter( (key) => enrollDict[key].courseBatch === grablessonsVue.lcParam.currentBatch.code ); } else { index++; }可以模拟每次选课都成功的状态。如果不放心的话，可以试一试。
这里的res.data.code==100是不是有问题 请求成功的code应该是200
好的，成功抢选的可以被移除，只是我的测试场景是未开始选课状态，因此在正式选课的时候就不会再出现这样的问题了，非常感谢！
这一段代码：
// if (res.data.code === 100) { if (true) { delete enrollDict[key]; // 移除成功的课程 methods.saveCourse(); window.Components.reloadList(); key_list = Object.keys(enrollDict).filter( (key) => enrollDict[key].courseBatch === grablessonsVue.lcParam.currentBatch.code ); } else { index++; }可以模拟每次选课都成功的状态。如果不放心的话，可以试一试。
这里的res.data.code==100是不是有问题 请求成功的code应该是200
这个不是我决定的...huhu大佬的原始版本如下
好的，成功抢选的可以被移除，只是我的测试场景是未开始选课状态，因此在正式选课的时候就不会再出现这样的问题了，非常感谢！
这一段代码：
// if (res.data.code === 100) { if (true) { delete enrollDict[key]; // 移除成功的课程 methods.saveCourse(); window.Components.reloadList(); key_list = Object.keys(enrollDict).filter( (key) => enrollDict[key].courseBatch === grablessonsVue.lcParam.currentBatch.code ); } else { index++; }可以模拟每次选课都成功的状态。如果不放心的话，可以试一试。
这里的res.data.code==100是不是有问题 请求成功的code应该是200
这个不是我决定的...huhu大佬的原始版本如下
了解了 今天选课试一试就知道了 这个功能也不是很碍事omo
1.0.3是相比原版修复了https未适配的问题，后面的2.x是有bug的，课程添加到列表里都没显示。从2.x版本起引入了延时功能，然而延时的影响忘记解除导致不能发出再次请求。3.0.1版本修复了延时的影响问题，相比1.0.3带来的新特性是列表里的选项自上至下以475ms延时逐个发出请求。3.0.1版本的更新禁止了延时遍历结束前的再次点击操作，但是冲突的点击操作是否被记忆？就是我的第二次点击失效了，在延时遍历结束后是否会自动帮我进行第二次遍历？另外，有人提出，实际的请求限制约是一秒钟不超过3条，认为可以三条请求一次性发出，然后延时一秒后再进行第二次同时请求，不过这样导致的问题就是如果遇到手快情况，三个选项均会失败。对于我目前而言，我更偏向考虑使用1.0.3版本，更加传统保守，问题是可能会因为连点导致请求全部失败。