Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New typedef modal: sync validation with backend #700

Closed
brprice opened this issue Dec 16, 2022 · 3 comments
Closed

New typedef modal: sync validation with backend #700

brprice opened this issue Dec 16, 2022 · 3 comments
Assignees

Comments

@brprice
Copy link
Contributor

brprice commented Dec 16, 2022

Currently the backend has some rules about what names are acceptable (they have to be unique in the appropriate sense). The frontend also has some rules, but they differ (at the very least, because the backend does not expose what constructor names already exist in any nice way! Thus checking for uniqueness is hard.) These should be brought into sync (or at least, the frontend should be stricter than the backend -- note that this logic is only for creation, not viewing. We would want the frontend to be able to view any type that the backend may give us, but viewing in general is future work)

Basic solution: improve the backend and manually implement the correct logic on the frontend. A perhaps better solution (automatically keeps in sync, but more network load): "preflight" the request -- on each change we could ask the backend "is this valid yet".

@dhess
Copy link
Member

dhess commented Dec 16, 2022

There are some obvious frontend checks we can do, such as looking for empty constructor names, and non-unique names, in the current typedef (i.e., the one that's being defined in the active form); but otherwise, we shouldn't try to be too clever in the frontend.

I think it makes sense to have 2 endpoints: one for preflighting typedefs (which makes no changes to the program, only checks the typedef vs the current program state) and one for creating typedefs. The endpoints can probably be identical save for the mutation semantics, and even return the same errors in case there's a problem with the typedef, which will simplify the logic on the client side.

We could trigger the preflight callback on certain events; e.g., the browser keyboard focus enters or exits a field in the form. We would trigger the creation callback upon pressing the Submit/OK button, and wait for the result from the backend before either dismissing the form (if successful) or displaying an error (if not).

This does seem like quite a bit of work for a UI which probably won't be used much once the student understands how to create more interesting types. I confess that I hadn't thought of how to view typedefs in the form UI that can't be created in the form UI. These 2 points make me wonder whether this UI will just be a temporary thing until we have a tree-based typedef UI.

@georgefst
Copy link
Contributor

Now that we've removed the form UI in favour of editing typedefs on the canvas (#863, #968 etc.), all typedef edits go through the action panel, but much of the discussion above is still relevant. If we try to enter a bad name, nothing happens and an error is logged in the console.

Perhaps this can be closed in favour of #869.

@dhess
Copy link
Member

dhess commented Nov 22, 2023

I think you're right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants