М
Когда редактирую стили в девтуле, они редачатся в оригинальном файле
Как исправить?
Ну или как сломать, что бы оно сорцы не видело
Как исправить?
Ну или как сломать, что бы оно сорцы не видело
Size: a a a
2020 October 15
D
Ребята, подскажите пож-та новичку. Пишу интерфейс. Данные нужно замокать из массива, либо захордкодить. В дальнейшем данные нужно буду получать от бека. Я только знакомлюсь с хуками. Правильно я понимаю, что если данные захородожены, то useEffect использовать не нужно, а если буду мокать из массива данные, то нужно использовать хук ?
NP
подскажите может кто знает в material ui при наведении кнопка становится темнее а нужно наоборот
как это сделать?
как это сделать?
И
Ребята, подскажите пож-та новичку. Пишу интерфейс. Данные нужно замокать из массива, либо захордкодить. В дальнейшем данные нужно буду получать от бека. Я только знакомлюсь с хуками. Правильно я понимаю, что если данные захородожены, то useEffect использовать не нужно, а если буду мокать из массива данные, то нужно использовать хук ?
Лучшее решение — писать фронт уже готовым к бэку — не хардкодить внутри компонентов, а хардкодить снаружи. Компоненты описывать так, будто они получают данные из бэка.
const getUsers = () => Promise.resolve(hardcodedUsersArray)
Тогда ты сможешь на этапе интеграции вместо переписывания компонента на хуки просто поменять реализацию getUsers и всё.
const getUsers = () => Promise.resolve(hardcodedUsersArray)
Тогда ты сможешь на этапе интеграции вместо переписывания компонента на хуки просто поменять реализацию getUsers и всё.
И
Ребята, подскажите пож-та новичку. Пишу интерфейс. Данные нужно замокать из массива, либо захордкодить. В дальнейшем данные нужно буду получать от бека. Я только знакомлюсь с хуками. Правильно я понимаю, что если данные захородожены, то useEffect использовать не нужно, а если буду мокать из массива данные, то нужно использовать хук ?
И так и эдак — хардкодить,но в зависимости от того, как хардкодить, тебе либо придётся компоненты переписывать, либо не придётся.
D
И так и эдак — хардкодить,но в зависимости от того, как хардкодить, тебе либо придётся компоненты переписывать, либо не придётся.
Отлично, огромное спасибо
И
Отлично, огромное спасибо
А ещё зацени miragejs или аналоги. Может, для новичка будет сложновато, но зато сразу будешь писать пиздато
D
А ещё зацени miragejs или аналоги. Может, для новичка будет сложновато, но зато сразу будешь писать пиздато
Ок👍
SM
А ещё зацени miragejs или аналоги. Может, для новичка будет сложновато, но зато сразу будешь писать пиздато
сложновато, я чекал.
SM
локалсторедж удобней
И
Soltukiev Malik
сложновато, я чекал.
Зато позволяет писать полностью интерактивные и продакшн-реди приложения на фронте совершенно без бэка. Отдаёшь схему бэкендеру, он по ней реализует апи, ты выключаешь мираж и всё работает
SM
Зато позволяет писать полностью интерактивные и продакшн-реди приложения на фронте совершенно без бэка. Отдаёшь схему бэкендеру, он по ней реализует апи, ты выключаешь мираж и всё работает
Ну да. Вот я не понял, как работает это mirage?
И
Soltukiev Malik
Ну да. Вот я не понял, как работает это mirage?
Перехватывает все сетевые запросы и обрабатывает у себя в кишках, не отдавая их в реальную сеть
SM
Перехватывает все сетевые запросы и обрабатывает у себя в кишках, не отдавая их в реальную сеть
Это я понял, но хранятся где эти данные?
И
Soltukiev Malik
Это я понял, но хранятся где эти данные?
В памяти. Перезагружаешь страницу, всё сбрасывается
SM
В памяти. Перезагружаешь страницу, всё сбрасывается
Лол, тогда это слабый аналог бэка, если данные сбрасываются.
И
Soltukiev Malik
Лол, тогда это слабый аналог бэка, если данные сбрасываются.
Это специальный инструмент, который заменяет бэк для РАЗРАБОТКИ. Не для прода, не для потестить, не для «запустить на локалке», а для РАЗРАБОТКИ.
И
Это специальный инструмент, который заменяет бэк для РАЗРАБОТКИ. Не для прода, не для потестить, не для «запустить на локалке», а для РАЗРАБОТКИ.
Ну и для end-to-end тестов
L
ты сравниваешь костыль и ящик с инструментами. как думаешь? в плане стайледы прекрасная технология, но зачем их брать для переопределения стилей ui кита когда у него самого есть апи для этого? не кажется чем то неправильным?
На скринах туториал MUI, используют оба способа, но не ясно в каких случаях что лучше использовать.
Вот как для себя разложил:
1 Если нужно залазить в
На сколько я понял то styled из MUI это просто синтаксический сахор для withStyles (это так?)
2 Если подключаем стили через
3 Если делаем новый компонент без переопределения то используем styled из styled-components
Вопросы:
1 Все верно понимаю?
2 Для простого переопределения когда не нужно лезть в
Вот как для себя разложил:
1 Если нужно залазить в
theme то использовать styled из MUIНа сколько я понял то styled из MUI это просто синтаксический сахор для withStyles (это так?)
2 Если подключаем стили через
className (если их много например разом в одном компоненте), а не привязываемся к сущности компонента, то используем makeStyles3 Если делаем новый компонент без переопределения то используем styled из styled-components
Вопросы:
1 Все верно понимаю?
2 Для простого переопределения когда не нужно лезть в
theme, лучше использовать styled из MUI или styled-components? Какие минусы у второго?L
ты сравниваешь костыль и ящик с инструментами. как думаешь? в плане стайледы прекрасная технология, но зачем их брать для переопределения стилей ui кита когда у него самого есть апи для этого? не кажется чем то неправильным?
