Задать вопрос

Vlad_Murashchenko

Ответы

  • Лучше стор или стейт?

    @Vlad_Murashchenko
    Предпочитаете держать состояние как можно ближе к месту которое его использует. Это позволит Вам лучше разделить ответственности между компонентами. Исходя из этого принципа:

    Если состояние Вашей таблицы нужно только в таблице, то лучше всего получать и хранить состояние Вашей таблицы прямо в "контейнер" компоненте (компоненте который знает о чем конкретно эта таблица, а не просто отображает абстрактную таблицу).

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

    Redux подойдёт, если данные используются разными частями приложения которые находятся далеко друг от друга(например на разных страницах). Если вы хотите чтобы после того как пользователь закрыл компонент, данные не старались из памяти. Если вам нужен Flux, транзакции, детерминированный Стейт менеджмент... Но для отображения данных таблицы скорее всего вам это не нужно.

    Помните о KISS, YAGNI - они очень помогают в принятии решений
    Ответ написан
    Комментировать
    Комментировать

  • Зачем нужны рефы в ReactJS?

    @Vlad_Murashchenko
    Не используйте ref, если можете обойтись без него. Эта возможность должна использоваться как можно реже. Через какое то время вы сами поймёте зачем это нужно, а пока просто пропустите и сосредоточьтесь на главе философия реакт.
    Ответ написан
    Комментировать
    Комментировать

  • Как сделать инпут, который может принимать телефон или email?

    @Vlad_Murashchenko
    Оставьте текстовым полем, не нужно никаких масок. На onBlur + onSubmit проверяйте что это корректный имейл или телефон, если ни одного ни другое показывайте ошибку. Это самое простое решение и его вам скорее всего будет достаточно.

    Можно добавить проверку во время ввода и которая будет проверять 2 случая сразу.
    1) введённые данные не подходит ни для одного ни для второго
    2) уже понятно, что это имейл, валидируем как имейл (в случае есть какая-то буква или @)

    Я также рекомендую вам использовать какое-то готовое решение для валидации, например vuelidate, чтобы оставить код декларативным и поддерживаемым. Однако в скором времени я планирую написать туториал о декларативной валидации своими руками.

    Решение которое предложил Дмитрий Беляев будет сложно поддерживать в проекте, хотя оно действительно решает задачу именно так как она была поставлена.
    Ответ написан
    Комментировать
    Комментировать

  • Работает ли clearTimeout внутри самого setTimeout() ????

    @Vlad_Murashchenko
    Просто добавь return в место своего clearTimeout
    Ответ написан
    Комментировать
    Комментировать

  • Можно ли так сделать на js и php?

    @Vlad_Murashchenko
    Да, можно, это называется COMET почитайте об этом на learnjs.ru там подробно расписаны разные реализации
    Ответ написан
    Комментировать
    Комментировать

  • Как грамотно организовать работу redux?

    @Vlad_Murashchenko
    Вам в любом случае нужно будет хранит access, refresh, access_expires_in, refresh_expires_in в каком-то защищённом месте недоступном для других приложений но доступном из js. Я использую для этого localStorage.

    Так что хранить эти данные в redux, равно как и отправлять их туда через dispatch не нужно, пусть localStorage будет единственным источником правды. Ничего специфичного для реакта здесь тоже нет.

    Напишите свой небольшой сервис auth который будет инкапсулировать в себе логику проверки токенов на актуальность, авторизацию, аутентификацию, обновления токенов, их очистки и хранения в localStorage.

    Перед каждым запросом делайте проверку аксесс токена, если он заекспайрился, то делайте рефреш откладывая все последующие запросы до его резолва, если рефреш не удался то просто кидайте пользователя на логин. В этом вам может помочь axios intercepters.

    С остальными я думаю вы разберётесь :)

    Также почитать про то как хорошо организовать работу с токеновми можно здесь https://gist.github.com/zmts/802dc9c3510d79fd40f9d...
    Ответ написан
    1 комментарий
    1 комментарий

  • Когда не использовать vuex | redux | flux?

    @Vlad_Murashchenko
    Все просто.
    1) состояние относится к какому-то конкретному компоненту, который сам несёт ответственность за CRUD с данным состоянием - используй локальное состояние.
    Пример: список каких-то элементов, мы ведь не захотим отобразить или поработать с элементом из этого списка где-то в другой части приложения, это ведь бред какой-то, хотя дизайнеры могут придумать всякие. И если они придумают то прийдется подымать это состояние выше или выносить в глобальное.
    2) если же состояние используется в разных компонентах которые не имеют прямого отношения друг к другу, тогда удобнее использовать глобальное состояние чтобы удобно внедрять его в нужные компоненты и предоставлять им интерфейс для работы с ним.
    Пример: сервер предоставляет нам объект юзера в котором есть статус, имя, фотография, какие-то ещё данные. Статус отображается и редактируется в одном компоненте, имя с фотографией отображается в другом, а редактируется в какой-то вообще отдельной форме со своим состоянием. Здесь нам бы пришлось держать данное состояние где-то очень высоко и далеко от компонентов которые им управляют, глобальное состояние упрощает работу с подобными состояниями
    Ответ написан
    Комментировать
    Комментировать