11
Январь
2023
Кейс — есть радио инпут, нам нужно спросить у юзера реально ли он хочет переключить значение? если нет — не переключаем
В моём случае радио инпут реализован в виде отдельного компонента.
Первое — v-model = item.value заменяем на биндинг значения :value = item.value и событие смены @change = changeValue(item, $event)) с передачей в него значения и непосредственно события $event
далее в методе changeValue(item, event) я сохраняю текущее и новое значения (конечно предварительно добавляем currentItem и eventItem в data)
this.currentItem = item (в this.currentItem ссылка на item)
this.eventItem = event (в this.eventItem ссылка на event)
и уже по результатам выбора пользователем в модальном окне либо изменяю значение
this.currentItem.value = this.eventItem
либо оставляю тоже самое
this.currentItem.value = JSON.parse(JSON.stringify(this.currentItem.value))
ВНИМАНИЕ!
тут небольшой лайфхак в виде переприсвоения самому себе такого же значения, но с обновлением ссылки!
this.currentItem.value = JSON.parse(JSON.stringify(this.currentItem.value))
иначе Vue не понимает, что у свойства изменилось значение и компонент радио инпута нужно отрендерить заново
рубрики: VUE JS |
11
Январь
2023
В текущем проекте уже на шаге сдачи заказчику обнаружили баг, который можно было исключить при правильном проектировании сущностей (по сути таблиц хранения данных).
Для наглядности сразу покажу скриншотик
Т.е. у подгружаемого документа может быть тип «скан документа» (редактируемый pdf,собираемый из jpg) либо готовый документ с отделённой подписью.
На этапе проектирования под оба варианта заложили одну таблицу … и теперь при переключении режима приходится стирать (через окно предупреждения) уже введённые файлы другого режима, что пользователю неудобно.
Этот недочёт при проектировании «цепляет» за собой проблемку с типизацией данных — из-за фактической разности в структуре сущностей автоматически «ловим» проблемы с типизацией при передаче данных на фронт.
(в моём проекте я ещё хуже «замутил» — в одно и тоже свойство запихал две абсолютно разные сущности (типа на фронте уже по полям объекта раскидаю что есть что) — так вообще делать нельзя !!!
Вообще нужно стараться придерживаться принципов максимального типизирования — на фронте в JS юзать Typescrypt, на бэке все передаваемые свойства распихивать по классам, ассоциативные массивы — ЗЛО, все ассоциативные массивы переделать на DTO (Data Transfer Object), … и так далее.
Всю логику максимально утаскиваем на бэк, фронт должен быть интуитивно понятен, без каких либо «наворотов» особенно по преобразованию входящих данных — всё это должно быть на бэке.
Ну и закончить хотел вопросом тест кейсов — при программировании в голове нужно держать все возможные варианты алгоритма. При эксплуатации вылезет всё — поэтому чтобы не переделывать, нужно стараться предусмотреть сразу всё.
В общем решил для себя составить базовый список основных кейсов при тестировании, куда отдельными строками нужно ввести:
* недоввод данных — пользователь открыл интерфейс ввода, ничего не ввёл или ввёл но потом нажал в браузере «назад» или просто закрыл без сохранения
* открытие страницы (редактирование или просмотр — где в параметрах страницы какие либо переменные) напрямую через ввод адреса в браузере
* фильтрация переменных в адресе — ввод в URL некорректных данных, разного диапазона (см.предыдущий пункт)
рубрики: Размышления |