Андрей безфамилии

У вас есть одно большое дерево, в котором хранится все состояние (state) приложения - это хранилище (store).
Также у вас есть набор редьюсеров (которые скомбинированы в один общий rootReducer) - это функции, который принимают текущее состояние и действие и возвращают новое состояние:

function someReducer(state = initialState, action) {
  // обычно выглядит как switch 
  // action - простой js-объект
  //              и обязательно имеет строковое поле type
  switch(action.type) {
    // обрабатываем действие с типом SOME_ACTION_NAME
    case 'SOME_ACTION_NAME':
      // берем какие-то данные из экшена и возвращаем новое состояние
      // при этом менять sate нельзя!
      // state.someProperty = action.newStateData <--- НЕТ!
      return { ...state, action.newStateData };
    // Если мы не обрабатываем действие - просто возвращаем старое состояние
    default:
      return state;
  }
}

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

function someActionCreator(someArg) {
  return {
    type: 'SOME_ACTION_NAME',
    newStateData: someArg + 5, // <-- разная логика
  };
}

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

Если мы хотим получить доступ к состоянию в экшен креаторе - воспользуемся thunkMiddleware:

import thunkMiddleware from 'redux-thunk';

function createStore(initialState) {
  const reducer = combineReducers(reducers);
  const finalCreateStore = applyMiddleware(
    thunkMiddleware // <-- добавляем middleware
  )(defaultCreateStore);
  return finalCreateStore(reducer, initialState);
}

Теперь мы можем делать так:

function someActionCreator(someArg) {
  return (dispatch, getState) => { // <-- возвращаем фукнцию, а не объект!
    const someState = getState().reducerName;
    return {
      type: 'SOME_ACTION_NAME',
      newStateData: someArg + someState, 
    };
  };
}

В общем схема выглядит так:

actionCreator --action--> dispatch --action--> middleware --action--> store --action--> reducer --> newState

Затем мы берем из react-redux метод connect, который подключает Ваш умный компонент к хранилищу:

import { connect } from 'react-redux';
import { bindActionCreators } from 'redux';

class MyComponent extends Component {
  static propTypes = {
    someProp: PropTypes.string.isRequired,
    someFunc: PropTypes.func.isRequired,
  };
}

// Тут мы берем из глобального состояния необходимую нам часть
// В ownProps - свойства компонента. Тут могут быть например свойства от роутера
function mapStateToProps(state, ownProps) {
  return {
    someProp: state.someReducer,
  };
}

function mapActionsToProps(dispatch) {
  return bindActionCreators ({ // <-- биндим все на disptach для удобства
    someFunc: (someArg) => someActionCreator(someArg + 1),
  }, dispatch);
}

export default connect(
  mapStateToProps,
  mapActionsToProps
)(MyComponent);

React.PureComponent реализует метод shouldComponentUpdate таким образом, что он делает поверхностное сравнение props и state (не глубокое). Вот собственно код:
https://github.com/facebook/react/blob/c8fbdac2271...

shouldUpdate =
            !shallowEqual(prevProps, nextProps) ||
            !shallowEqual(inst.state, nextState);

Что такое shallowEqual? Это по сути сравнение оператором === каждого элемента из prevProps с каждым элементом из nextProps. На всякий случай дам ссылку на реализацию для полного понимания: https://github.com/facebook/react/blob/6963ea4bfcd...

В итоге всё зависит от структуры ваших props. Если в props вы передаёте объекты которые иногда мутируются, т.е. по ссылке они равны ===, но внутри какие-то данные поменялись (что само по себе выглядит странно в экосистеме redux + reselect, но вполне возможно технически), тогда использование PureComponent вам всё поломает, т.к. на экране какие-то компоненты перестанут перересовываться!

Если же у вас всё по уму, данные которые передаются через props являются скалярными типами (string, int, float, bool) или immutable объектами, тогда смело используйте PureComponent - в некоторых случаях он поможет избавиться от лишних вызовов render.

Важное замечание: PureComponent нужно использовать только для так называемых presentational components, т.е. для тех компонент, которые НЕ обёрнуты в вызов redux connect().

Для container components (т.е. тех компонент, которые обёрнуты в redux connect()) нет смысла наследоваться от PureComponent, т.к. метод connect() оборачивает ваш компонент своей реализацией shouldComponentUpdate, которая также использует shallowEqual. Если вы по недосмотру унаследуете container component от PureComponent - ошибок не будет, но это не имеет никакого смыла, т.к. ваш код по сути будет дважды делать shallowEqual, а зачем делать лишнюю работу?

Подводя итог, рецепт такой:
- presentational components наследуем от React.PureComponent
- container components (которые обёрнуты в redux connect()) наследуем от старого доброго React.Component

Есть один вариант. Самый крутой.
НЕ ИСПОЛЬЗОВАТЬ БУТСТРАП :)

https://github.com/jescalan/rupture

1. Почему многие компании в своих вакансиях на позицию джуна html указывают в требуемых умениях знания PHP(либо базовые либо средние)

По тому, что два феерически популярных шаблонизатора, таких как Blade и Twig наипсаны на PHP. И сам по себе PHP - отличный шаблонизатор, достаточно скачать и положить куда-нибудь на диске (т.е. ставить не обязательно) PHP, запустить встроенный сервере и использовать его в купе с gulp->browser-sync, получается отличная связка без всяких Apache'ей, для разработки - идеально. Так же, применение подобных связок позволяет не писать например, 8 раз 1 и тот же блок, а просто засунуть его в цикл и вывести 8 раз. Итог - меньше кода, проще работать.

MySQL, работу с БД

По тому, что при умении работать с MySQL - хотя бы базовом, а так же при помощи дюжины строк кода PHP, вы можете доставать данные прямо из БД и выводить их в макете, работая с реальными данными, а не с "Lorem ipsum'ами".

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

Проекты бывают разные, например в средней по размерам фирме, где я сейчас работаю, меня назначили тех. директором (т.к. почти 20 лет опыта и всё такое). Если бы я пошел работать в Google, наверное, там бы я был джуном... если бы вообще кем-то был :D (условно конечно, но думаю Вы понимаете о чём я). Другой пример, когда я устраивался на работу в международную IT-компанию, там среди требований на сеньёра была такой список знаний, что я немного прифигел, среди прочего было свободное владение английским и желательно ещё каким-то (кроме родного) языком, к знанию PHP добавлялось отличное знание кардинально противоположенного языка, например, Java, C++ или C#, отлично знание линукса и сетей и т.д. С другой стороны, человек работающий в фирме "3 разраба", на должности "Сеньёр", не обладает даже 10% знаний, озвученных в другой фирме на эту же должность (в эту фирму я тоже пытался устроиться). Т.е. фирмы бывают разные и требования тоже.

Почему на именно на джуна столько требований, я честно говоря, точно сказать не могу. Т.к. джунов обычно набирают, что бы "воспитать" себе разработчика нужной категории. Выше озвученные мной эпитеты скорее являются ответами на все остальные вопросы, кроме вопроса "зачем всё это именно джуну". Но, возможно это показывает желание человека развиваться в целом, а не зациклится на чем-то одном и "свято верить в чудеса". Люди, которые "научились делать что-то одно", в профессиональном IT обычно долго не держатся, наглухо увязая в массах себе подобных, которые тоже умеют делать "что-то одно" а потом бегают по фрилансам и депмят цены до такой степени, из начального бюджета, который и без того, был не велик (например, 5тыс. руб.) он порой превращается в 200-300руб., лишь бы урвать кусок работы. Можно "делать что-то одно", а знать в общей сложности нужно всё, т.к. дизайнер без знания основ работы браузера - очень хреновый дизайнер. А верстальщик, без знания основ фотошопа - очень плохой верстальщик.

P.S. Зачем в требованиях пишут "умение рисовать в фотошопе" - я даже приблизительно себе представить не могу, т.к. именно "рисовать" - это на 100% задача дизайнера/художника, и это на 97% та задача, которая к верстальщику не относится вообще никак, почти так как умение штукатурить стены, к вёрстке не имеет вообще никакого отношения, даже косвенного.

Что выбрать, слайдер на чистом CSS или с использованием JS?

Ответьте на следующие вопросы и ответ придет сам собой:

• Можете ли вы в слайдере на чистом CSS сделать поддержку touch-устройств (свайпы)?
  
• Можете ли вы в слайдере на чистом CSS сделать поддержку клавиатуры (фокус на весь слайдер и переключение слайдов стрелками)?
  
• Можете ли вы в слайдере на чистом CSS адекватно останавливать его на hover, чтобы юзер мог прочитать написанное на слайде?
  
• Можете ли вы в слайдере на чистом CSS легко добавить или убрать слайд, не сломав все остальное?
  

P.S.: Как человек, создающий всякое на чистом (и не очень) CSS, понимаю ваше стремление, но продукт делается в первую очередь для пользователей.

Как вариант можно глянуть на Visual Studio Code от Microsoft. Также кроссплатформенный, имеет плагины, темы и поддерживает множество языков. Хоть и основан на тех же технологиях что и Atom, но намного шустрее.

(+-) atom: на конец ноября 2016 еще сыроват
(-+) brackets: глючный, использую только для быстрого извлечения слоев из psd
(-) phpstorm: для простой веб-разработки (лендинги, битрикс, джумла, вордпресс, ..) излишен
(+) sublime text 3: для веб-разработки идеален (быстрый запуск, emmet, быстрая проверка кода на ошибки (php/html/css/js-linter, xdebug), autobackups, sftp, быстрый git из редактора, быстрый доступ к gist, быстрое сравнение файлов/директорий (с интеграцией meld), быстрый поиск файлов и текста в файлах проекта, доступ к терминалу из редактора, быстрое увеличение/уменьшение значений digits, px, true/false, .. (inc-dec-value), список задач (plaintasks), простая работа с проектами (project manager), легко настраиваемые хоткеи (поиск выделенного в google, php.net, ..), просмотр результата верстки в браузере без перезагрузки (livereload), иконки файлов проекта (file icons), свои и сторонние готовые сниппеты, корректная работа с кодировками, проверка орфографии, разнообразные темы оформления интерфейса редактора и синтаксиса кода, ..) и т.д. (привел неполный список того, что настроено у меня сейчас); из минусов (имхо): порой не хватает аналога atom commander (плагину file navigator порой не хватает функциона и удобства); порой в плагине sftp не хватает 1) как в atom remote-ftp сайдбара по дереву удаленного сервера для быстрой навигации в глубину сайта 2) вывода прав доступов к файлам и дат последних модификаций; часть элементов интерфейса не получится настроить через темы/настройки; проприетарное по

ubuntu 16.10 x64, asus x501a: 15", cpu b980, ddr3 8gb