WeReng, сохранять стейт — это хорошо. Но нужно понимать — когда этого делать не нужно.
Не нужно сохранять стейт при ошибках. Человек ушел с экрана — ошибка должна исчезнуть.
Но если человек писал комментарий, ушел с экрана, вернулся обратно, а недописанный комментарий сохранился в инпуте — это прикольно. Я делал так в одном редакторе постов — все данные до момента публикации или сохранения в черновики сохраняются в окне редактора. Можно обновить страницу, можно вообще выйти из приложения — вернувшись в редактор юзер увидит то, что было написано до этого.
Короче :) отвечая на ваш вопрос — удаляйте ошибку при размаунте основного компонента. Или ставьте колбек по таймауту на скрытие.
lamer350, я бы очень хотел надеяться, что вы правы:) Сафари не могу, потому что активно работаю и за пк и за маком — нужен один браузер. Да и есть вещи в Хроме, которых нет в Сафари и которых не хватает.
testertoster, в смысле как? У вас в объекте неправильная дата. Это по-русски так правильно - день-месяц-год. В США пишут месяц-день-год. Очевидно, 30 месяц - это не то, что вам нужно.
Товары «шины мишлен супер-зима 13 радиус» и «шины мишлен супер-зима 15 радиус» — это разные товары. Это разные комплекты шин с разным количеством на складе и разной ценой. Единственное, что их объединяет — это модель «супер-зима».
Соответственно, есть смысл держать эти товары в базе по-отдельности, а при выборке уже объединять в одну карточку все товары «супер-зима».
Так вы сможете не выдумывать свои структуры данных (как хранить радиусы и цены в одной строке) и будете иметь контроль над количеством, если, конечно, складской учет так же разграничивает эти товарные позиции.
Так, наверное, надо начать с проектирования api. Чтобы там были методы, которые необходимы во фронте. Фронт вообще не должен знать про устройство таблиц в бд.