У меня возникли проблемы с поиском хороших ресурсов для того, какие лучшие практики будут для разработки Flutter, особенно для обработки форм.
Все, что я нахожу при отправке форм, довольно ясное, но проблема в том, что все они имеют логику проверки и логику отправки непосредственно в виджете формы. Мне это не нравится, так как кажется, что это очень быстро станет очень запутанным с более чем, скажем, 3 входами и какой-либо более чем базовой логикой проверки. Это также, кажется, нарушает разделение интересов, думая, что я должен был быть большой вещью во Flutter/Dar (по крайней мере, из того, что я читал).
Поэтому моим решением для этого был мой класс FormHandler, который я определил в файле form_handler.dart. Он имеет несколько статических методов для проверки ввода, несколько методов для обработки отправки и formInput типа Map<String, dynamic> для хранения пар ключ-значение пользовательского ввода.
Это работает следующим образом:
form_handler.dart:
class FormHandler {
// make new form handler with empty map
FormHandler({required this.formInput});
// for storing input key value pairs
Map<String, dynamic> formInput;
// Form submissions
// new course
void submitCourse({required formKey}){
final form = formKey.currentState;
// save on validate
if ( form.validate() ){
form.save();
// then make new course via the database controller
}
}
// Input validations
static String? validateTextInput(String? input){
if ( input == null || input.isEmpty ){
return 'Field must not be empty';
} else {
return null;
}
}
}
Мне просто интересно, хорошее ли это решение, каковы возможные подводные камни, какие-либо предложения и т. д.
Мне это кажется хорошим решением, но я хотел бы получить отзыв от кого-то с большим опытом, чем у меня.
Спасибо, Сет.
Вы можете обратиться к этому каналу YouTube для получения инструкций. Вот ссылка на видео, связанное с текстовыми полями и проверкой — https://thewikihow.com/video_2rn3XbBijy4
Общепринятой практикой было бы создание объектов-значений или сущностей, которые содержат логику для проверки самих себя. Возможно, с интерфейсом (абстрактным классом) в качестве основы, чтобы убедиться, что вы не забыли реализовать такую проверку.
Тем самым перемещая такую логику проверки из пользовательского интерфейса и вместо этого заботясь о том, что важно в вашем домене. Можно будет проверить в нескольких местах вашего кода, а не только из формы, что не так легко достижимо с вашим предлагаемым решением. Ваше решение по-прежнему смешивает пользовательский интерфейс с логикой через formKey. Вы можете захотеть проверить «вещи», когда вы получаете данные из своего бэкэнда, или выполнять другие расчеты/изменения значений позже в приложении.