p
Нет, потому что товар может кончится
Size: a a a
2020 July 26
AO
он нажал на кнопку Оформить и вот пока он там заполняет форму...
AO
p
Или его может не быть
AO
ну он сначала всё равно общие поля заполняет
AO
типа ФИО адрес
AO
откуда забрать - это ведь потом можно спросить
AO
наверное, ещё есть вариант скомпоновать из нескольких аптек
AO
это было бы удобно
AO
если одно есть только тут, другое только там
AO
вообще, с 300 точками эти вычисления должны быть достаточно быстрыми
AO
это же не 300 млн точек
AO
ну и ещё можно кешировать всё-таки (это будет иметь смысл если заказывают 3 и более товаров)
AO
пока пользователь нажимает на кнопки добавить в корзину
AO
тогда в финальном варианте будет 300 (кеш<i> + стоимость последнего добавленного товара)
AO
ну и ещё можно кешировать всё-таки (это будет иметь смысл если заказывают 3 и более товаров)
скажем, через 3 секунды после последнего нажатия на кнопку добавить в корзину, + или - (чтобы не делать лишних вычислений если он быстро меняет количество)
AO
это повысит скорость вывода суммы, но и слегка повысит вероятность ошибки резервирования
AO
ну и ешё кажется, что тут важнее задержки сети, чем время вычислений, а если так, то в браузер будет подгружаться быстрее
AO
можно подгружать цены в IndexedDB и там же считать кеши, при повторном входе пользователя на сайт обновлять цены на те, что было закешировано недавно (есть вероятность, что закажет то же самое), кеши стоимости корзины, разумеется, одноразовые...
p
скажем, через 3 секунды после последнего нажатия на кнопку добавить в корзину, + или - (чтобы не делать лишних вычислений если он быстро меняет количество)
Там меньше миллисекунды на go )