Once hackworthltd/vonnegut#844 is merged, we'll have a complete type-checker for typedefs, but not all of these rules will be captured in our current frontend's typedef UI. The typedef UI does a good job of checking for constructor name clashes within the type you're defining, but not much else.
We decided in hackworthltd/vonnegut#844 not to make changes to our current frontend, since we're not going to be using it for much longer and it's not a good use of time. But we do need to think about what we'll do when we re-implement the simple typedef UI in our new frontend.
My preference is that we do not try to replicate any of the typechecking rules in the new frontend, because a) then we'd have to keep them in sync with any changes to the backend rules, b) we'd have to test both, and c) we'd have to do it in TypeScript. One of the tenets of our new frontend is to keep it as Primer-unaware as possible — we want to spend our frontend development time focusing on good UI/UX, not implementing language features.
This would require adding a new, "type-check this definition, but don't add it to the program yet" API call. This should be trivial.
What's less obvious is how to hook this up to the frontend. Should we call it on every keystroke? (The typedef UI is one of the few places where we require students to type freely on the keyboard.) Should we batch up keystrokes and only call it every time the batch size is met (or some amount of time passes since the last keystroke)? Should we just poll it every n seconds?
@brprice points out that there may be latency issues with a server-side-only solution. Personally, I think that latency issues in a UI form where students will be typing are the least of our latency concerns, as strictly speaking we only need to give a "yes/no" when the student tries to submit the form — everything else is just an optimization, really — but maybe I'm wrong and it'll be really annoying. (Also see hackworthltd/vonnegut#847)
Anyway, this is something we'll need to hash out for Primer.
Once hackworthltd/vonnegut#844 is merged, we'll have a complete type-checker for typedefs, but not all of these rules will be captured in our current frontend's typedef UI. The typedef UI does a good job of checking for constructor name clashes within the type you're defining, but not much else.
We decided in hackworthltd/vonnegut#844 not to make changes to our current frontend, since we're not going to be using it for much longer and it's not a good use of time. But we do need to think about what we'll do when we re-implement the simple typedef UI in our new frontend.
My preference is that we do not try to replicate any of the typechecking rules in the new frontend, because a) then we'd have to keep them in sync with any changes to the backend rules, b) we'd have to test both, and c) we'd have to do it in TypeScript. One of the tenets of our new frontend is to keep it as Primer-unaware as possible — we want to spend our frontend development time focusing on good UI/UX, not implementing language features.
This would require adding a new, "type-check this definition, but don't add it to the program yet" API call. This should be trivial.
What's less obvious is how to hook this up to the frontend. Should we call it on every keystroke? (The typedef UI is one of the few places where we require students to type freely on the keyboard.) Should we batch up keystrokes and only call it every time the batch size is met (or some amount of time passes since the last keystroke)? Should we just poll it every n seconds?
@brprice points out that there may be latency issues with a server-side-only solution. Personally, I think that latency issues in a UI form where students will be typing are the least of our latency concerns, as strictly speaking we only need to give a "yes/no" when the student tries to submit the form — everything else is just an optimization, really — but maybe I'm wrong and it'll be really annoying. (Also see hackworthltd/vonnegut#847)
Anyway, this is something we'll need to hash out for Primer.