согласен с Вами.
Думаю, что воспользуюсь Realm, для сохранения всех объектов. У каждого объекта добавлю булевый параметр is_synced. Если что-то меняю на ios клиенте - is_sync будет false до тех пор, когда с сервера не придет ответ (по сути, обновит существующую запись).
dollar, с сервера я могу прислать json-файл всего состояния приложения для юзера. Ну и сохранить его. Другой вопрос - что приложение связано с веб-версией, ну и еще андроид также) Поэтому, оффлайн режим надо обеспечить лишь частично, в режиме чтения)
не совсем понятно, как это применимо к фильтрам. У меня модель, которая содержит в себе цвет, размер, скидку и тд - как строковые значения.
Проблема в том, что каждый раз необходимо показать только доступные (после предыдущего) значения фильтров.
Сейчас я делаю так: собираю все значения, и с помощью __in фильтрую. На выходе имеем отфильтрованные товары.
Но, получается, что необходимо сохранять предыдущий QuerySet, дабы дать возможность юзеру выбрать еще значения (например, после 2 этапа у нас доступно 5 цветов).
Мне кажется, что здесь налицо фасетный поиск? или же можно обойтись и стандартным django orm + js на клиенте?
Pavel Denisov, это да. Просто у нас есть промежуточный слой - бекенд. Необходимо, в первую очередь, четко обработать все действия на стороне django. Думаю, логично форму оплаты отдать под управление Django, где прописать все success/failure колбеки. Ну и уже после - редирект обратно в React-приложение, с уже обновленными данными.
Не знаю, насколько верна моя логика, но, я б довел юзера до кнопки "оплатить", и далее сделал редирект на django (с нужными параметрами). Ну и далее уже django сделает свою часть.
Есть либа - django-paypal, в которой все формы уже прописаны, колбеки и тд - удобно.
Pavel Denisov, еще такой, возможно, странный вопрос, но не могу вразумить.
Правильно ли я понимаю, что форму и саму кнопку необходимо делать на стороне Django? То есть юзер жмет "upgrade", его кидает на форму оплаты, сформированную django? Ну и после успешной оплаты, происходит обновление поля у юзера и редирект обратно в апп? или же форму можно и на клиенте сформировать? тогда как в этом случае ловить сигнал об успешной оплате и обновлять необходимые поля у юзера?
То есть вопрос именно в разделение части React, и Django
Pavel Denisov, Благодарю за разъяснение.
Правильно ли я понимаю, что инвойс придет как колбек. Соответственно, все необходимые данные будут уже в ответе от платежной системы? и далее мы уже ищем у себя в системе данный инвойс с нужным номером (который отправили), и обновляем статус подписки?
Дабы юзеру отослать вовремя письма о предупреждении окончания подписки (кол-во дней), и то, что подписка завершена (необходимо продлить).
Неверно сформулировал: не пересчитывать, а вовремя проверить и отключить (если закончилось).
Pavel Denisov, Да, согласен.
сделал 3 сущности: Тариф, Подписка, ПлатежнаяОперация.
Юзера связываю с Подписка с помощью OneToOne. По умолчанию - trial.
С помощью celery - каждый день провожу пересчет оставшихся дней.
Самое сложное, видимо, это привязать систему оплату (карта, paypal)
Да, необходимо отдельное поле for_sale_price, и туда забивайте цену со скидкой.
Если, например, необходимо добавить слайдер цены (price range) - с помощью aggregate и MIN, MAX функций вычисляйте минимальную и максимальную цену и выводите в шаблон.
При фильтрации примерно так:
Думаю, что воспользуюсь Realm, для сохранения всех объектов. У каждого объекта добавлю булевый параметр is_synced. Если что-то меняю на ios клиенте - is_sync будет false до тех пор, когда с сервера не придет ответ (по сути, обновит существующую запись).