Ответы пользователя по тегу React Native
  • Не корректные типы props для компонента React native styled components?

    Robur
    @Robur
    Знаю больше чем это необходимо
    const Item = (props: {item: Data}) => ...

    а у вас получается сейчас два пропса: id и value

    ну и Test потом тоже надо правильно протипировать чтобы props.item пришел нужного типа
    Ответ написан
  • Можно ли получить предыдущий роут react-router-dom?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Вам надо просто при переходе с registration на login не добавить а заменить роут

    было: /main -> /solvation -> /registration
    переходите на /login, становится: /main -> /solvation -> /login

    в этом случае все работает как надо автомагически.

    Заменить роут - смотря как вы его реализовали, если через то https://reacttraining.com/react-router/web/api/Lin...
    Ответ написан
  • Что такое React Native?

    Robur
    @Robur
    Знаю больше чем это необходимо
    А чем вас не устроили ответы с сайта самого React native?

    Если вкратце - все можно, погружаться сильно не придется, но в любом случае в то как устроена мобильная разработка вникнуть придется
    Ответ написан
  • Как отправить большое видео на апі из react native?

    Robur
    @Robur
    Знаю больше чем это необходимо
    вот тут посмотрите: https://gist.github.com/nandorojo/c641c176a053a9ab...
    Если верить тому что там написано, надо просто путь к файлу передать в xhr. Я не проверял.
    Ответ написан
  • Grapqhl backend и React native app. Стоит-ли объединять?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Нормально вам тимлид говорит, если сделать это грамотно. Single Source Of Truth рулит.

    - разные проекты вполне могут оставаться разными проектами используя один и тот же общий для обоих код. Способов это сделать много. монорепа, модуль, реестр схемы например.
    - у вас уже взаимная зависимость - общий GraphQL API. Вы вряд ли сможете поменять схему в одном проекте и оставить её старой в другом. Возможность хранить схему отдельно и менять независимо - это не гибкость, это прямая дорога к тоннам проблем и куче потерянного времени. Вас не смущает то что каждый раз меняя схему в одном месте надо обязательно сходить и поменять ее в другом чтобы они были всегда синхронизированы, и если вы этого не сделаете/забудете/опечатаетесь/не так скопипастите то что-то где-то обязательно сломается? Именно в этот момент стоило бы почувствовать что-то неладное.
    - если вы не видели чего-то - это не значит что то, чего вы не видели плохо, а то что видели - хорошо.

    В общем, делать стоит - главное делать грамотно. Если вы сейчас весь код в одну кучу свалите то конечно ничего хорошего не выйдет.
    Ответ написан
  • Лучшее решение повесить обработчик на событие?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Кем "не рекомендуется"?
    Чтобы решать проблему нужно убедиться что есть проблема и четко сформулировать ее.
    Если вы решаете проблему что код не подходит под какие-то рекомендации, то это одно, а если вы решаете проблемы с памятью во время выполнения приложения это совсем другое.
    Во втором случае у вас на руках должны быть данные полученные в результате анализа того как ваше приложение работает.
    Подавляющее большинство render функций вызывается на самом деле достаточно редко чтобы это имело значение.
    Ответ написан
  • Как правильно структурировать реакт проект?

    Robur
    @Robur
    Знаю больше чем это необходимо
    делаете папку shared (или как больше нравится) куда складываете все что нужно использовать в разных компонентах.
    Если появляется необходимость что-то куда-то перенести - то это не "проблема", это нормально, берете и переносите, приложение поменялось - структура оптимальная уже другая.
    Ответ написан
  • Как правильно работать с сессиями в reactjs?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Вашему фронтендщику стоит посоветовать сначала изучить как это делается а потом огород городить.
    но судя по тому что вы вместо него это выясняете, его все устраивает а вас - нет.

    Так конечно никто не делает, есть понятия аутентификации и авторизации, сессия устанавливается после аутентификации (пользователь подтверждает что он - это он) и потом этот пользователь авторизуется с каким-то правами и в сессию каким-нибудь подходящим образом ставятся атрибуты авторизации, в простейшем случае - роль пользователя (админ/юзер). Эти атрибуты фронт может запросить у бэка отдельным запросом или получить в ответе на /login.

    Не очень понятно что значит "запрос для входа пользователя" и "запрос для входа менеджера" -
    у вас предполагается что пользователь будет нажимать на разные кнопки "войти как менеджер" и "войти как пользователь" или что?

    Нормально так:
    Кнопка для логина - одна.
    запрос аутентификации - один.
    сервер отвечает ошибкой или успешным ответом. Сама сессия ставится кукой, эта кука по хорошему должна быть httpOnly и из js кода не доступна. С ней работает исключительно бэкенд и так как хочет.
    Аппа из ответа сервера (в body) либо сделав отдельный запрос (типа /currentUser) понимает что это за пользователь - менеджер или обычный и сохраняет это куда-то себе. В случае реакта это с большой вероятностью стор. Можно в localStorage чтобы при перезагрузке читать сразу оттуда.

    Дальше аппа просто смотрит в стор в нужные моменты чтобы понять что пользователю показывать что нет.
    Все права на запросы бекенд разруливает на основе сессионной куки которая приходит с каждым запросом автоматически. То есть сессии как таковой фронт вообще никак не касается - его дело - вызывать login/logout, получить от бэка инфу о текущем юзере и правильно обрабатывать 401.

    Можно сделать и более сложные варианты - без куки, с каким-нибудь токенами и прочим, но скорее всего вашему фронтэндщику еще рано.
    Ответ написан
  • Как вы работаете с react native?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Лайфхак чтобы все смотрелось секси - взять и бросить пару хобби, освободившееся время потратить на изучение доков, примеров, особенно внимательно посмотрите "разработку интерфейсов" и UX. Так же время нужно чтобы пробовать разный код и смотреть что получилось. Если не будет получаться - выделить больше времени за счет отказа от личной жизни.
    Из технических приемов (не лайфхаков) - больше времени уделять на проработку интерфейса, мобильные приложения - не то же что веб, одним резиновым меню по верху страницы и выравниванием колонки контента по центру не обойдешься. Придется продумывать как оно должно выглядеть на разных разрешениях, и возможно даже менять лэйаут полностью при сильно большой разнице. Это если секси, если попроще - то просто сделать два варианта - телефон и планшет и для каждого размеры/шрифты делать больше или меньше в зависимости от размера экрана
    Ответ написан