Demian Smith

Вам может помочь объект formState:

const { isDirty, isValid } = formState;
return <>{isDirty && isValid && <button />}</>

Вот так:

const [modalIsVisible, setModalIsVisible] = useState(false);

return (
  <>
    <button onClick={() => setModalIsVisible(true)}>Show modal</button>
    { modalIsVisible && <Modal onClose={() => setModalIsVisible(false)} /> } 
  </>
)

Для того чтоб привлечь контрибуторв нужно для начала привлечь пользователей. Для этого:

1. Дайте внятное описание того какую задачу решает проект. Пока по описанию проекта видно как он создан, но не что делает. Желательно уложить это описание в одно-два предложения, которые идут сразу после заголовка проекта
   
2. Это UI проект? Где ссылка на демо?
   
3. Вас в комментариях уже спросили, почему он называется my_...? Сейчас проект выглядет как поделка для личного использования
   
4. Необходимы инструкции по установке. Желательно в виде npm install project_name, а не в виде нескольких абзацев текста
   
5. Прогоните описание хотя бы через grammarly. Сейчас там слишком много "русского английского"
   
   

Сделаейте

.catch(err => reject(err))

а не

.catch(err = reject(err))

и перестанет ругаться.

Проблема в том что SASS файлы компонентов - это отдельные модули, не связанные с "глобальными" стилями. Для того чтоб переиспользовать миксины, переменные и прочее, создайте отдельный файл, например _utils.scss, где бы лежали эти самые миксины и переменные. И импортируйте _utils.scss в те компоненты, где они нужны.

Несколько лет назад я попытался заморочиться и сделать так чтоб миксины подключались по умолчанию где-то из настроек, но с наскока у меня не получилось - это раз. А два - поразмыслив, я пришел к тому, что это не верно, потому что при глобализации миксинов программист теряет возможность чистого и прозрачного экспортирования компонент в сторонние модули. Такие дела.

Потому что роут "/" срабатывает раньше чем "/task/:id". Поменяйте их местами и проблема исчезнет. Реактовский роутер жадно выбирает все роуты, которые подходят по маске. Роут "/" наименее специфичный, поэтому будет срабатывать всегда.

Для того чтоб подобной проблемы не возникало, необходимо расставлять роуты от более специфичным к менее, например "/a/b" -> "/a" -> "/".

Так же можно добавлять роутам атрибут "exact". Тогда роутер будет выбирать точное совпадение, а не вхождение.

Потому что key должен быть уникальным значением, а у вас используется одно и тоже значние для кадого элемента списка. Самый простой и примитивный способ заткнуть реакт чтоб он не ругался на отцуствие ключа, это сделать как-то так:

taskList.map(function(item, idx) {
  return (
    <p className="task" key={idx} >{item}</p>
  )
})

Но способ лучше - это организовать структуру состояния таким образом, чтоб уникальный ключ хранился в каждом элементе списка. Типа того:

taskList = [
  {id: 1, objective: 'Buy milk'},
  {id: 2, objective: 'Learn React'},
]

taskList.map(task => (<div key={task.id}>{task.objective}</div>))

Когда меня просят оценить код на Ангуляре, то всегда вангую непонимание Rx. Это одновременно самая сильная и самая слабая сторона Ангуляра. Сильная в том плане что это невероятно мощный инструмент. А слабая в том что порог вхождения в Rx крайне высок. Невозможно просто так взять, начать проект с RxJS, разобраться походу и в итоге сделать хорошо. Нужно заранее знать с чем имеешь дело. Я не знаю как объяснить эти принципы в двух словах, или дать какую-то формулу успеха.

Вот лекция, которая в своё время мне помогла:

https://www.youtube.com/watch?v=3LKMwkuK0ZE

Она по RxJS 5, но принципиально ничего не поменялось.

Это из того что сразу бросается в глаза почти на любом проекте, не только на вашем.

Из плюсов:

- понимание что такое компоненты
- плоская структура проекта

Из минусов (не считая Rx):
- отсутствие модулей

Я бы еще поставил под сомнение необходимость папок services и shared, но это скорее всего вкусовщина. Кстати, если у кого-то сейчас бомбануло от предыдущего предложения, можете плиз направить меня куда-то где бы это по-человечески объяснялось? А то я реально не понимаю зачем нужны эти папки, и зачем провайдеры, работающие с Http называть сервисами. Я так подозреваю что народ копирует эту идею друг у друга. Но могу быть с удовольствием неправ.

Можно картинку поместить в ту же папку где и CSS файл. Тогда в CSSнике можно будет сделать url('./image.jpg'), а вебпак это дело разрулит во время компиляции и поместит картинку куда надо.

Если вы пришли в Реакт и модульные бандлеры (ака Вебпак) со старого доброго Галпа или вообще без него обходились раньше, то такой подход немного ломает стереотип. Мы привыкли хранить картинки в папке public/images, а стили в папке public/styles. Но в мире вебпака совершенно нормально хранить стили и статитику рядом с кодом. Собственно, вебпак и нужен для того чтоб это подключать и распределять как нужно.

В последнее время стал популярен подход так называемого Модульного ЦСС (CSSModules): это когда стили и статические файлы относящиеся к компоненту хранятся в папке компонента. Сам Вебпак позаботится о том чтоб во время компиляции положить стили и статику куда нужно. За это мы его и любим.

https://firebase.google.com/docs/database/web/read...

Вот этот запрос в гугле привёл меня к решению https://www.google.com/search?newwindow=1&sxsrf=AL...

Как говорится, "inglish - velikaya sila"

Удалите папку node_modules и после этого выполните команду npm install.

Я бы на вашем месте делал это без ифа, потому что внутри ифа сложно будет сказать к какому именно блоку относится `.thumbnail-container-images`.

Можно сделать так:

$(".thumbnail-container:not(.with_thumb) .thumbnail-container-images").css("width","77%")

Что означает: присвоить всем .thumbnail-container-images, которые находятся внутри .thumbnail-container:not(.with_thumb) ширину 77%.