Поэтапная регистрация Django?

sim3x, спасибо большое

Поэтапная регистрация Django?

sim3x, приглашения есть, да.
Просто если создаётся воркспейс для команды, то для его создателя это целесообразно делать на этапе регистрации

Поэтапная регистрация Django?

sim3x, у них при регистрации workplace это идёт вторым этапом

Поэтапная регистрация Django?

sim3x, так и должно быть, что дефолтная команда юзера имеет адрес username.example.com.
Как в Monday или Slack

Поэтапная регистрация Django?

sim3x, при регистрации юзер может выбрать, остаётся он в своей приватной команде или же будет создавать ещё одну. Ну и если выбрал "ещё одну", то спрашиваем название, сабдомен, далее валидируем и редиректим.

Поэтапная регистрация Django?

sim3x, можно, конечно, разделить на два этапа: юзер и его команды. На первом этапе создаётся юзер, на втором - команда.

Поэтапная регистрация Django?

sim3x, наоборот, это делает процесс регистрации более понятным. Юзер заполняет поля, и ему вывалиивается не весь список ошибок, а присущий только данному этапу.
Примеры: slack, Monday.

Поэтапная регистрация Django?

sim3x, да. Их гораздо больше, просто сократил.
Возможно, FormWizzard подойдёт?

Стоит ли использовать Mongo в связке с Django+Postgre?

Pavel Denisov: думаю, что да, так и поступлю. json - поле использовал на одном из проектов, где необходимо было хранить различные свойства для товара (фильтры). Возможно, и для данного случая можно попробовать что-то аналогичное.

Стоит ли использовать Mongo в связке с Django+Postgre?

Pavel Denisov: Павел, примерно так)))
К вопросу проектирования всегда подхожу очень тщательно, поэтому, и пытаюсь понять/уяснить/устранить минусы и выявить/использовать плюсы каждого подхода)

Стоит ли использовать Mongo в связке с Django+Postgre?

RidgeA: Моделей, пока, не так много. Но, думаю, их количество будет расти. Используется и DRF и channels (для мгновенного обновления - задачи "многопользовательские").
Вот и задумался над тем, даст мне что-нибудь (в плане, производительности, упрощения запросов) mongo или же нет. Выходит, что лучше и далее развивать этот стек, без вмешательства mongo?

Стоит ли использовать Mongo в связке с Django+Postgre?

Вот я пытаюсь понять, стоит ли вообще такая идея.
Прочитал ряд статей, в частности, про стек трелло, в котором они описывают, что монго такая крутая и бла-бла).
Насколько я понял, можно будет сохранять коллекции объектов, и после их быстро вытаскивать (в уже json-формате).

Какую схему задействовать для автообновления веб приложения?

Как вариант, можно также задействовать centrifugo
Но, насколько я правильно понимаю, общение все равно будет идти через сокет

Какую схему задействовать для автообновления веб приложения?

Благодарю за ответ.
Channels превосходно работает? Как работает авторизация у Вас через token?
Вы для каждой сущности создаете группу? или же одная общая группы для всех изменений?

Как вы организуете SEO в django?

rmfalx: сделал так.
1. Создаем абстрактную модель SeoModel:

class SeoModel(models.Model):
    seo_title = models.CharField('Title', blank=True, max_length=250)
    seo_description = models.CharField('Description', blank=True, max_length=250)
    seo_keywords = models.CharField('Keywords', blank=True, max_length=250)

    def get_seo_title(self):
        if self.seo_title:
            return self.seo_title
        return ''

    def get_seo_description(self):
        if self.seo_description:
            return self.seo_description
        return ''

    def get_seo_keywords(self):
        if self.seo_keywords:
            return self.seo_keywords
        return ''

    class Meta:
        abstract = True

И в другой модели, где необходимо нам SEO, наследуемся:

class Product(SeoModel):
поля для этой модели

Ну и уже в шаблоне, где у нас titile, description, keywords - вызываем get_seo_title, get_seo_description, get_seo_keywords.

{% block seo %}
    <title>{{ product.get_seo_title }} {{ usersettings.seo_title }}</title>
    <meta name="description" content="{{ product.get_seo_description }}"/>
    <meta name="keywords" content="{{ product.get_seo_keywords }}"/>
{% endblock %}

Если это просто страницы - то будет SEO для конкретной страницы.
В моем случаем - это были товары и категории. Поэтому я выводил SEO для этих сущностей.
Заполняется - с админки для каждой модели. При этом (если увидеть логику работы методов абстрактного класса) - если поля title, keywords, description не заполнены, то выводим название продукта/категории.

Как вы организуете SEO в django?

Добрый день.
django-seo не стал использовать, так как куда удобнее просто создать абстрактную модель, с необходимыми сео-поля (title, description, keywords) и унаследоваться от данной модели.

Redux c большим объемом данных в Store?

Никита Гущин: спасибо)
да, я в каждом компоненте прокидываю только нужные state'ы. То есть если это страница юзера, то вытаскиваю из state только сущность "user".
Больше всего "тормоза" вызывает перетаскивание (drag-and-drop) с позиции на позицию, когда я беру объект, тащу его и после прохожу по каждой задаче, дабы поменять sort-свойство (в зависимости от позиции).
На небольшом объеме все работает хорошо, если больше - тормоза (когда задач около 500). Думаю, что можно смело ограничить объем задач в одном борде до 200 штук и вывод проводить не по всем объектам в сторе, а только по задачам данного списка.

Redux c большим объемом данных в Store?

Никита Гущин: нет, не использую. Судя по вопросам, люди работают и с 5000 записей в сторе, и все ок. Просто у меня одни и те же задачи используются в разных местах (панели), и было бы совсем нелогично вешать на эти панели свои запросы к АПИ. "Единый источник правды" должен сохраняться (да и удобнее это).
Можно в двух словах, для чего использовать reselect?
Спасибо

Redux c большим объемом данных в Store?

Никита Гущин: Как вариант, и судя по различным ответам со stackoverflow, люди предлагают использовать immutable.js. Как я понимаю, это позволяет не пробегать каждый раз целиком весь массив.
То есть самое долгое по времени, в случае больших объемов, будет начальная загрузка (initiail state).

Redux c большим объемом данных в Store?

davidnum95: можно грузить только "видимые" задачи, и те, что входят в панель "важные", например. Тогда объём данных уменьшится.
И сделать ограничение на количество задач в проекте до 200 штук (мол, если юзер делает 201 задачу, то пусть делает новый проект). Думаю, что по поводу 200 задач можно не переживать)