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

More idiomatic usage of Flask-Wtf and WTForms #647

Open
brassy-endomorph opened this issue Oct 5, 2024 · 0 comments
Open

More idiomatic usage of Flask-Wtf and WTForms #647

brassy-endomorph opened this issue Oct 5, 2024 · 0 comments

Comments

@brassy-endomorph
Copy link
Collaborator

Is your feature request related to a problem? Please describe.

We are using only a tiny fraction of the power of Flask-Wtf and WTForms and this leads to several problems:

  1. Code duplication and magic strings that have to be kept in sync between Flask endpoints (python code) and HTML templates.
  2. Because we manually code the HTML for the form fields, adding a new form field means having to update the HTML, and even adding an extra validator (or removing one) means having to add/drop markup like required for a field.
  3. We manually populate form fields rather than using built-in helpres.
  4. In tests we use Python dicts (i.e., untyped unsynced code) to pass data to endpoints.
  5. We don't use common Flask-WTF patterns to ensure submitted forms retain their data in case of error
  6. Errors are not displayed on their relevant fields
  7. Form submission handling is cluttered and chaotic in endpoints (e.g., /settings/) and will only get worse as we add more settings. Each settings tab should be its own page/endpoint instead of frontend nav with JS

Describe the solution you'd like

This ticket if fully implemented would be quite large, so this is grounds for discussion and possibly splitting into multiple tickets. There are two methods for implementing this.

  1. Implement fixes for one of the above numbered issues one at a time for the whole app
  2. Fully implement all changes for one endpoint at a time to have a pattern we can copy to new and existing endpoints

I think 2 makes more sense because there's interplay between the above issues and solving one class of issues at a time might make for duplicated code or wasted work if it goes a direction with incompatibilities or dead ends.

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

1 participant