You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Code duplication and magic strings that have to be kept in sync between Flask endpoints (python code) and HTML templates.
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.
We manually populate form fields rather than using built-in helpres.
In tests we use Python dicts (i.e., untyped unsynced code) to pass data to endpoints.
We don't use common Flask-WTF patterns to ensure submitted forms retain their data in case of error
Errors are not displayed on their relevant fields
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.
Implement fixes for one of the above numbered issues one at a time for the whole app
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.
The text was updated successfully, but these errors were encountered:
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:
required
for a field./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 JSDescribe 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.
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.
The text was updated successfully, but these errors were encountered: