uRoot

Удаленки сравнительно много. Работаю так уже несколько лет. Проекты попадались разные, но должен сказать, что совсем говно было только в рандеву (ущербный ИМ косметики), куда я устроился разгребать. По сравнению с этим, а также с тем, что мне попадалось на проектах от фриланса, на удаленке отличный код. Как правило, если компания продуктовая или около того, есть команда с тимлидом, которая, в целом, следит за своим репозиторием, проводит код-ревью. Если компания делает проекты на заказ, то не все так плохо - во-первых, там можно взять на себя весь проект (бэк или фронт) и делать все самостоятельно, прося старших коллег провести ревью иногда. У меня были все эти варианты. Сейчас работаю в продуктовой команде, где жесткие код-ревью, но все репы вылизаны и почти идеально чисты. Очень много времени тратят на архитектуру. Так что далеко не все так страшно, фриланс куда страшнее. Я с него начинал, и мне есть, с чем сравнить. Удаленка после российского фриланса - это рай.

Куда не стоит идти удаленно? В не-IT-контору. Т.е. туда, где IT не является основным способом заработка. Это, внезапно, ИМ (чем крупнее, тем ущербней), различные организации, которым просто нужен крутой сайт (строительные, например). Исключения, конечно, бывают - так, делал админку для биоинженеров. Вот это был интересный проект, уникальный - когда еще доведется поработать с настоящими учеными, вывести на экран информацию о генетике различных видов, запилить сравнение генотипов? Хотя конечно, на фронтендера ученый люд смотрит примерно как фронтендеры на дворника или доставщика пиццы )

Из минусов отмечу тот факт, что работать тяжело. Тяжело нарушать work-life баланс. В офисе ты можешь уйти домой в 18 и оставшийся день заниматься чем угодно; дома же ты можешь обнаружить себя в 16 с чипсами и сериалом, а в 20 за допиливанием фичи, которую завтра уже выкатывать надо. Нужен самоконтроль. Поэтому для идеальной удаленки нужен офис. Например, коворкинг какой-нибудь, или просто отдельная комната для работы.

Кроме того, стоит примириться с тем, что в белую не все возьмут. Это гемор с документами, налоги, обычно те, кто ищет на удаленку, не хотят с этим заморачиваться. Попадаются еще те, кто предлагает удаленку с визитами в офис, такой, промежуточный вариант. Вывод - стоит иметь ИП.

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

Конечно. Там от вас не будут требовать работать 24\7, но нужно уметь закрывать ишью в трекере с приемлемой скоростью, выдавать результат. Если сможете продуктивно работать дома, сможете давать результат, то можете завершать работу хоть в 16 дня. У меня лично дома так не получается, продуктивнее всего работается в антикафе каком-нибудь.

P.S. Также отмечу, что бэкенда PHP \ Laravel \ Symfony на удаленку мало. Если и встречается, то Yii, чаще встречается Ruby, Python, Go. Вот фронта много.

onChange={this.props.filterItems}

filterItems = ({ target: { name, checked } }) => {
  this.setState({
    [name]: checked,
  });
}

от нуля и до самолёта, и выше.
средней цены вообще не существует. вернее она существует, но ни на что не влияет.
весь вопрос: за сколько можно это впарить клиенту. и от средней цены он не зависит, от слова совсем.

работа стоит ровно столько, сколько за нее готов платить потребитель.

Последняя версия ios на iphone4 7.2. Bottstrap 4 сделан на flexbox. Полноценная поддержка flexbox начинается с версии ios 9.2 (с версии 5, но с префиксами и танцами). В вопросе нужно указывать, что за технологии используешь, кто отвечает должен все комменты посмотреть, прежде чем ответить? А ещё лучше посмотреть поддержку на mdn или на аналогичных ресурсах.

Добавь в общий State новое свойство, которое будет отвечать за твои option из селекта. Там просто будет строка с нужным названием



Затем создай отдельно функцию filter которая будет брать массив, фильтровать его и отдавать новый массив. Всё это взависимости от строки которую ты установил в state



Затем создай переменную VisibilityItems (видные item) и возьми тот основной массив который у тебя был в state и прогони через эту функцию фильтрации и передай как свойство компоненту табоицы. У меня код тут немного другой, но думаю логика понятна.



То есть логика стейта такая. У тебя первоначально есть какой то массив в стейте. И в стейт добавляется новое свойство filter которое является строкой. Далее в компонент ты передаёшь массив, который прогоняется через функцию. Сам основной массив в стейте ни за что не трогай :)

Использую в продакшене JSS, стили в виде объектов в отдельных файлах. В плане написания, по сути ничем не отличается от CSS с пре/пост-процессорами. Еще один из доводов в пользу CSS-in-JS, упрощение сборки проекта.

Не слушайте ретроградов, которые до сих пор БЭМ юзают для решения проблемы изоляции стилей.

https://habr.com/p/480358/

Как по мне, CCS-in-JS очень специфичная штука, хотя в продакшене можно встретить довольно часто.

Местами, его использование оправдано, например:
- При работе с динамически выделяемыми css свойствами, например когда обычный calc уже не справляется
- При очень сложном динамическом лейауте
- При темизации компонентов и вообще существовании такой концепции как "Тема" внутри вашего проекта.

Тем не менее, минусов как по мне не меньше:
- Проблема кеширования, такие стили не могут быть закешированы, т.к генерируются на лету и требуют того чтобы браузер распарсил ваш компонент и добавил стили в DOM. + Как результат намного больший размер финального бандла проекта.
- Хаос в файлах, когда приходится держать вместе компоненты и их стили. Опять же решаемо, но те проекты которые я видел, которые используют концепцию CSS-in-JS по большей части фигачат обычные статические стили, просто используя js нотацию, а изначально задумка была не в этом. Для такого, давно придумали более эффективные решения.
- Отвратительный DX при дебаггинге.

Если подрезюмировать, то в целом есть некоторые задачи который этот подход хорошо решает.
Если не можете с уверенностью сказать, что да CSS-in-JS решает мою задачу - использовать его не стоит.
Использование технологии ради технологии, не привидет ни к чему хорошему. Во всех остальных случаях использование более классического стека в виде или чистого CSS или любого из препроцессоров более оправдано.

Используют очень много людей. Дело вкуса. Удобно делать темизацию, в ущерб читабельности и производительности.

Глянь на количество загрузок npm styled-components, пользуются ими многие, особенно в react. Удобно, компактно, все в одном месте. Вот компонент, вот к нему стили, вот динамика в зависимости от пропсов или чего-то еще. Все это дело компилируется в css код с уникальными и не пересекающимися именами классов, все это вставляется с тег стилей. Потом элементу подставляется тот или иной класс. Это значит, что производительность будет идентичная, что и при классическом использовании.

Конструктор нужен, если вам нужно что-то сделать один раз при первом вызове компонента. Например, ранее в конструкторе реакт компонентов делали биндинги методов класса, чтобы указать им контекст.

Если вам нужно просто объявить стейт, вызывать конструктор - это, чаще всего, избыточно.

Это в дополнение к тому, о чём вам уже написали. Я бы вам советовал почитать про конструктор в ООП вообще, не ограничиваться реакт компонентами

Он нужен не в React, а в классе.
В данном случае можно сделать и так и так.

const result = graphData.map((n, i) => ({ ...n, color: palette[i % palette.length] }));

или, в более общем виде:

const combine = (arr, keys, values) =>
  arr.map(({ ...n }, i) => (
    values.forEach((m, j) => n[keys[j]] = m[i % m.length]),
    n
  ));


const result = combine(graphData, [ 'color' ], [ palette ]);

да, но этот объект вам недоступен и детали его реализации могут быть разными.
Можете для простоты считать что переменная "записывается" в блок в котором определена. Тот что "{}"
получить все переменные этого блока в виде объекта нельзя, да и не нужно.
от работы с переменными определенными в window тоже следует избавляться - это плохая практика.