Владимир Родкин

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

Посмотрите Jest. Оптимизирован для тестирования React
Jest

Как было уже написано, да нужно использовать thunk-middleware, код которого кстати, очень простой!
Суть в том, что нужно проверить: если ваш action возвращает функцию - значит прокинь в него dispatch и getState и жди что будет дальше, а если ваш action - простой объект (как и задумывалось) - сразу прокинь его дальше. Так и работают middleware - добавляя функционал и пробрасывая выполнение дальше.

У меня есть подробное руководство по redux на русском, посмотрите здесь - https://www.gitbook.com/book/maxfarseer/redux-cour...

Спасибо.

"Не дает покоя фраза на оф вики Debian"
Это не про вас. Это про сервера, там совершенно другое понятие "безопасности".

Вообще без разницы что ставить. Под Ubuntu будет больше информации касаемо проблем с desktop вещами (а-ля Глючит видюха в игре ХХХ).

И как дополнение: если учесть все вышесказанное, то какой по вашему вариант мне бы больше подошел?

ArchLinux + тайловая wm. Полный контроль над системой + самые свежие обновления.

Для работы с promise Вам нужно использовать дополнительный middleware - promise middleware. Существует несколько реализаций - можете выбрать любой понравившийся. Я использую этот и относительно него буду далее писать.

Как я понял, запрос пишется в action creator при помощи промиса

Да, все так. В экшен-креаторе делаем запрос, возвращаем экшен с промисом. Далее promiseMiddleware подхватывает его и вместо одного экшена диспатчит 3 - действие началось, действие завершилось успешно, действие завершилось с ошибкой. Все это происходит в зависимости от того в какое состояние попал вышеупомянутый promise. Другими словами - "действие началось" диспатчится сразу; если запрос успешен - диспатчится "действие завершилось успешно".
Соответственно в вашем редьюсере Вы подписываетесь на это три действия. Пример:

// action creator
import fetch from 'isomorphic-fetch';

export default function getBook() {
  // Для запросов чаще всего используется  isomorphic-fetch, который возвращает promise
  const promise = fetch(url, options);
  return {
    types:  [ 'GET_BOOK-BEGIN', 'GET_BOOK-SUCCESS', 'GET_BOOK-FAILURE' ],
    promise,
  };
}

// reducer
import {GET_BOOK} from '../actions/books';

const booksReducer = (state = {}, action) => {
  switch (action.type) {
    case 'GET_BOOK-SUCCESS':
      // При успешном завершении у нас установлено свойство result с ответом сервера
      return action.result;
    case 'GET_BOOK-FAILURE':
      // При неудачном завершении у нас установлено свойство error с описанием ошибки
      doSomethingWithError(action.error); // <--- просто для примера
    default:
      return state;
  }
};

export default booksReducer;

UPD1 К слову: у редакса есть отличный пример, где все это можно в живую посмотреть - https://github.com/rackt/redux/tree/master/example...

Мне кажется, вариант вполне нормальный. И вот: habrahabr.ru/post/266559

Все красиво объяснил Nkly777, только в блоке PS merge с rebase перепутаны.
Добавлю картинок.

git rebase devel - собачка на молнии - "сшивает" коммиты по дате их создания
(ветка devel "растворяется" в основной ветке)

git merge devel - пожарная лестница, все коммиты ветки devel крепятся в конец, образуется пересечение
(devel остается отдельной веткой, к которой можно вернуться)

git chery-pick idea - забрать коммиты из ветки idea

Сначала научитесь программировать, потом идите работать в какую то контору которая игры делает, и все поймете.

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

Плюс ответы можете гуглить на gamedev.ru

Имхо, при выборе ноутбука для кодинга, единственные важные критерии — это клавиатура и экран.

Берите macbook pro 15 retina, не прогадаете

Реализуйте unit-of-work, identity map и шаблон репозиторий на JS. Эдакую абстракцию позволяющую выделить persistence layer.

Других идей под чистый JS нет. Все остальное будет хоть как-то связано именно с DOM и т.д.

вот пример на jQuery и jPlayer:
jsfiddle.net/9avkgtgm