I wonder if it's a good idea at this point to make a Task class in client/templates/teach/code.js. It seems that this would make a lot of things more convenient and give better encapsulation. It's not that important though.
For the match result, the extra data being returned (what I called simplified_median, source_segment, target_segment) for UI purposes seem a bit arbitrary. Is there something more principled we can do here, like the entire simplified source and target, plus a mapping from one to the other? We don't have to address it now, but it seems like there is some room for improvement there. In fact, since it's not clear what the best matching algorithm is going to be at this point, I think it's fine to punt this issue.
I like the refactoring! With regards to your notes:
Agreed both that it can be done but isn't a high priority at the moment.
We could avoid returning this other data by having match return an affine transform that would map the user's stroke to the matched stroke. That's what all the data is used to compute, anyway. Do you think that's reasonable?
Two notes:
Task
class inclient/templates/teach/code.js
. It seems that this would make a lot of things more convenient and give better encapsulation. It's not that important though.simplified_median
,source_segment
,target_segment
) for UI purposes seem a bit arbitrary. Is there something more principled we can do here, like the entire simplified source and target, plus a mapping from one to the other? We don't have to address it now, but it seems like there is some room for improvement there. In fact, since it's not clear what the best matching algorithm is going to be at this point, I think it's fine to punt this issue.