Artur
Норм ли практика хранить параметры запроса к api в redux???
🦜
простыми словами после успешной авторизации необходимо обновить render в app.js
history.push('/dashboard')
🦜
Farik
А как по правильному делается это?
Farik
просто идея такая что-бы по пути '/' была форма авторизации в случае если не авторизован, если авторизован то открываю страницу
🦜
А как по правильному делается это?
если тебе нужен dashboard на / то там и рендери этот компонент.
авторизация и регистрация на урлах
auth/login
auth/register
auth/logout
Стас
Всем привет)
Нуждаюсь в помощи, никак не могу для себя найти, как устроены хуки реакта в плане синхронности/асинхронности. Если с классовым this.setState все более-менее понятно, он асинхронен, и если хочется работать с данными, которые изменяешь - передавай коллбэк или используй функцию внутри. С useState нельзя передать вторым аргументом функцию. Никак не могу найти, приведет ли код вида
setModalTitle(title);
setModalMessage(message);
setModalVisible(true);
К неожиданным сайд-эффектам. Судя по тому, что вижу - не приводит, но хочется узнать наверняка)
Спасибо за внимание, помогите разобраться пж, кто в курсе. Или тыкните в мануал, потому что я не нашел разбора этого момента нигде)
Eldar
просто идея такая что-бы по пути '/' была форма авторизации в случае если не авторизован, если авторизован то открываю страницу
Вообще идея с condition в component в Route не очень хорошая идея - так не делают
Для этого сделали в Route параметр render в котором ты определяешь как и что рендерить
Ты можешь реализовать свою логику и нарямую вызывать у объекта истории refresh, но логика твоя получается не совсем корректная и не укладывается в концепцию
Выше тебе написали как обычно делают в таких случая роутинг, это стандартный подход)
Стас
useEffect используй вместо колбэка, как завещал Денчик Абрамов
То есть сделать еще один сайд-эффект с обзервером для этого конкретного случая, нечто вроде
useEffect(() => {
changedModalTitleAndMessage && setModalVisible(true);
changedModalTitleAndMessage && setChangedModaltitleAndMessage(false);
}, [changedModalTitleAndMessage])
showModal = (title, message) => {
setModalTitle(title);
setModalMessage(message);
setChangedModalTitleAndMessage(true);
}
?
artalar
Vladimir
Max
подскажите пожалкйста мб кто-то сталкивался, когда билжу андроид
./gradlew buildRelease
такая ошибка
Execution failed for task ':app:transformDexArchiveWithDexMergerForRelease'
Program type already present: io.invertase.firebase.BuildConfig
при билде в дебаг все работает
Vlad
🦜
data аттрибуты очень мощная штука, с помощью которой можно избежать создания лишнего кода, как пример анонимные функции в замыкании
artalar
Да вот только это все в реальный дом идет
artalar
А оно там не надо
Nikolai
Pavel
вроде через спред пропсов это фиксилось
artalar
Да вот только это все в реальный дом идет
Нужны react-атрибуты 🙂
Типа добавил префикс какой-то, и в ДОМ это не уйдет
<Component !prop={‘never been in DOM’}>
Pavel
или омит ненужных ключей через lodash/ramda когда спредишь пропсы на компонент
Vadim
artalar
Сейчас !prop попробует пойти в дом, если оно все прозрачно спредится
Sergey
Стас
Есть ли инфа, хуки useState синхронны или нет?
Sergey
Сейчас !prop попробует пойти в дом, если оно все прозрачно спредится
Кажется это проблема разрабочика.
Ничего не мешает сделать так
({ prop: _noDom, ...props }) => (<div {...props}/>)
artalar
Не очень однозначно.
ну это пример… надо подумать 🤷♂️
Вообще в JSX иногда не хватает отдельного синтаксиса под какие-нибудь ништяки
Давайте еще пофантазируем. А что если мы бы могли передавать контекст без провайдера:
<Child (myContext)={value}>
Nikolai
Есть ли инфа, хуки useState синхронны или нет?
Стейт меняется асинхронно, если в этом был вопрос
Sergey
🦜
ну это пример… надо подумать 🤷♂️
Вообще в JSX иногда не хватает отдельного синтаксиса под какие-нибудь ништяки
Давайте еще пофантазируем. А что если мы бы могли передавать контекст без провайдера:
<Child (myContext)={value}>
тогда бы каждый реакт элемент проходил проверку на наличие получения контекста
artalar
Кажется это проблема разрабочика.
Ничего не мешает сделать так
({ prop: _noDom, ...props }) => (<div {...props}/>)
Да но я не хочу так делать 🙂 Хочется разделить как-то разные типы пропсов: контекст, прямые пропсы, пропсы для DOM, колбеки (с автоматической мемоизацией)… Например
Sergey
Да но я не хочу так делать 🙂 Хочется разделить как-то разные типы пропсов: контекст, прямые пропсы, пропсы для DOM, колбеки (с автоматической мемоизацией)… Например
Кажется что это путь во vue с его кучей всяких вариаций аттрибутов :)
artalar
тогда бы каждый реакт элемент проходил проверку на наличие получения контекста
не, это скорее просто шорткад на провайдера, только что бы девтулзы не захломлять.
Ну и я просто фантазирую
artalar
Кажется что это путь во vue с его кучей всяких вариаций аттрибутов :)
На самом деле можно просто
<Component props={{
own: {…},
DOM: {…},
child: {…},
}} />
Типа того. Это нормальное решение, проблема в том что оно не стандартизировано
Стас
Стейт меняется асинхронно, если в этом был вопрос
const [a, setA] = useState('');
const [b, setB] = useState('');
const [content, setContent] = useState('');
const changer = () => {
setA('foo');
setB('bar);
setContent(a + b);
};
return (
<>
<button onPress={changer}/>
<div>
{content}
</div>
</>
);
Вопрос состоит в том, будет ли выполняться changer синхронно и попадут ли 'a' и 'b' в setContent измененными
Стас
const [a, setA] = useState('');
const [b, setB] = useState('');
const [content, setContent] = useState('');
const changer = () => {
setA('foo');
setB('bar);
setContent(a + b);
};
return (
<>
<button onPress={changer}/>
<div>
{content}
</div>
</>
);
Вопрос состоит в том, будет ли выполняться changer синхронно и попадут ли 'a' и 'b' в setContent измененными
В случае классового this.setState - это очевидно, с хуками - для меня пока неочевидно)
artalar
На самом деле можно просто
<Component props={{
own: {…},
DOM: {…},
child: {…},
}} />
Типа того. Это нормальное решение, проблема в том что оно не стандартизировано
or https://medium.com/@dschnr/better-reusable-react-components-with-the-overrides-pattern-9eca2339f646
Adv0cat
На самом деле можно просто
<Component props={{
own: {…},
DOM: {…},
child: {…},
}} />
Типа того. Это нормальное решение, проблема в том что оно не стандартизировано
Не совсем нормальное, больше кода придется писать))
🦜
В случае классового this.setState - это очевидно, с хуками - для меня пока неочевидно)
useEffect(() => {
setContent(a + b)
},[a,b])
Стас
useEffect(() => {
setContent(a + b)
},[a,b])
а в случае, если я делаю тоггл модалки в setContent, и хочу показать модалку только после того, как a И b обновились?)
Стас
useEffect(() => {
setContent(a + b)
},[a,b])
const showModal = ({ message = ChangePasswordScreenConstants.DESCRIPTION, title = ChangePasswordScreenConstants.NEW_PASSWORD }: ShowingModalInfo) => {
setModalTitle(title);
setModalMessage(message);
setModalVisible(true);
};
🦜
а в случае, если я делаю тоггл модалки в setContent, и хочу показать модалку только после того, как a И b обновились?)
ну, читай доку про хуки я тебе показал чо сделать надо
Nikolai
const [a, setA] = useState('');
const [b, setB] = useState('');
const [content, setContent] = useState('');
const changer = () => {
setA('foo');
setB('bar);
setContent(a + b);
};
return (
<>
<button onPress={changer}/>
<div>
{content}
</div>
</>
);
Вопрос состоит в том, будет ли выполняться changer синхронно и попадут ли 'a' и 'b' в setContent измененными
нет, нет. content вообще можно из хука убрать и считать напрямую, если он только от a и b зависит
Таймураз
Нужны react-атрибуты 🙂
Типа добавил префикс какой-то, и в ДОМ это не уйдет
<Component !prop={‘never been in DOM’}>
Зачем оно если и так можно контролировать, что ты отдаешь в компонент?
Стас
ну, читай доку про хуки я тебе показал чо сделать надо
Я тебя понял. Доку я читал, и не нашел ответа на свой вопрос.
В любом случае, спасибо за затраченное время.
artalar
Зачем оно если и так можно контролировать, что ты отдаешь в компонент?
Там дальше
https://t.me/react_js/738048
Стас
нет, нет. content вообще можно из хука убрать и считать напрямую, если он только от a и b зависит
Ситуация примерно такая:
const showModal = ({ message = ChangePasswordScreenConstants.DESCRIPTION, title = ChangePasswordScreenConstants.NEW_PASSWORD }: ShowingModalInfo) => {
setModalTitle(title);
setModalMessage(message);
setModalVisible(true);
};
И модалку я хочу показать ТОЛЬКО после того, как стейт поменялся и для тайтла, и для месседжа
Таймураз
На самом деле можно просто
<Component props={{
own: {…},
DOM: {…},
child: {…},
}} />
Типа того. Это нормальное решение, проблема в том что оно не стандартизировано
Это с архитектурной точки зрения охереть как коряво=)
Таймураз
Не говоря о том, что не имеет смысла
Anatoliy
подскажите пожалуйста, чтобы импортировать svg as ReactComponent, что нужно сделать? смотреть в конфиг вебпака?
artalar
Не говоря о том, что не имеет смысла
https://medium.com/@dschnr/better-reusable-react-components-with-the-overrides-pattern-9eca2339f646
🦜
artalar
(инженер в Убер)
Стас
подскажите пожалуйста, чтобы импортировать svg as ReactComponent, что нужно сделать? смотреть в конфиг вебпака?
впихнуть svg код в твой реакт-компонент, и все
Danila
Ситуация примерно такая:
const showModal = ({ message = ChangePasswordScreenConstants.DESCRIPTION, title = ChangePasswordScreenConstants.NEW_PASSWORD }: ShowingModalInfo) => {
setModalTitle(title);
setModalMessage(message);
setModalVisible(true);
};
И модалку я хочу показать ТОЛЬКО после того, как стейт поменялся и для тайтла, и для месседжа
const modalIsVisible = useMemo(()=>title!==props.title && message!==props.message, [title, message])
Anatoliy
впихнуть svg код в твой реакт-компонент, и все
зачем делать лишние обертки, если как я понимаю можно из коробки так импортить
🦜
да
import { ReactComponent as Logo } from './logo.svg';
const App = () => (
<div>
{/* Logo is an actual React component */}
<Logo />
</div>
);
Стас
зачем делать лишние обертки, если как я понимаю можно из коробки так импортить
как реакт компонент - нельзя, только в качестве src для img
Anatoliy
ах, вот оно что
Таймураз
https://medium.com/@dschnr/better-reusable-react-components-with-the-overrides-pattern-9eca2339f646
Тот же архитектурный подход используется в react-select
Но делать это частью стандарта не нужно, потому что как минимум это реализовывается уже сейчас.
Если сделать подобное апи- очень много людей начнет себе стрелять в ногу. Реакт не зря абстракция над дом деревом
artalar
Таймураз
Тот же архитектурный подход используется в react-select
Но делать это частью стандарта не нужно, потому что как минимум это реализовывается уже сейчас.
Если сделать подобное апи- очень много людей начнет себе стрелять в ногу. Реакт не зря абстракция над дом деревом
Типа да, круто, в умелых руках поможет делать более реюзабельные компоненты, но:
Есть другие способы писать реюзабельные компоненты (например, познать связность и SOLID)
Таймураз
А в чем стрелять в ногу?
У меня в проекте попробовали реализовать что-то подобное, профукали один момент, так как хорошо не знали некоторые вещи в реакте и жсе и прострелили ногу всем
Андрей