Игорь Шумиловский

Чуть шире опишите, что вы хотите сделать. Как открывается popup – у него просто свойство "открыт"/"закрыт", или метод, который надо вызвать? По-хорошему, сверху вниз спускается через `props` состояние этого popup'а.

Чтобы не строить длинные лестницы props'ов, посмотрите Context в React.

Если нужен querySelector() – т.е. получить сам DOM-элемент – то есть ReactDOM.findDOMNode().

Насколько я понял, у вас есть две сущности (одна - root и одна в elements). Тогда это дело лучше хранить в нормализованном состоянии: делам два редьюсера, каждый работает со своей сущностью, а в селекторе денормализуем. При этом хранить сущности удобнее как { id: entity } объект, а не как массив.

// rootEntity reducer
const initialState = {
  entities: {}
}

function rootEntityReducer(state = initialState, action = {}) {
  switch(action.type) {
    case ADD_ELEMENT:
      const { targetEntityId, element } = action.payload
      const targetEntity = state.entities[targetEntityId]
      return {
        ...state,
        entites: {
          ...state.entities,
          [targetEntityId]: { ...targetEntity, elements: [ ...targetEntity.elements, element ] }
        }
      }
    default:
      return state
  }
}

UPD1 если entities - массив

// rootEntity reducer
const initialState = {
  entities: []
}

function rootEntityReducer(state = initialState, action = {}) {
  switch(action.type) {
    case ADD_ELEMENT:
      const { targetEntityId, element } = action.payload

      return {
        ...state,
        entites:  state.entities.map(
          entity => entity.id !== targetEntityId
            ? entity
            : { ...entity , elements: [ ...entity.elements, element ] }
        )
      }
    default:
      return state
  }
}

4-8 будет работать в одноканальном режиме, то есть медленнее.

С каким бекендом Вы предпочитаете связывать свое приложение?

Обычно REST/HTTP API/RPC прячут нюансы реализации бэкэнда. Так что без разницы, лишь бы апишка была удобная.

Каков Ваш стек в этом плане?

php, symfony2, postgresql. В любом случае разработчика SPA это волновать должно в последнюю очередь.

Так же интересует выбор баз (MySql, MongoDB....)

никогда не используйте mongodb как основное хранилище. Любая реляционная база на простых задачах (а на простых задачах nosql не нужен) будет проще и эффективнее. Говорю это основываясь на своем горьком опыте. Храните в mongodb агрегации денормализованных данных для ускорения выборок из реляционок. то есть в mongodb должны быть либо простые независимые данные (логи например) либо read-only данные.

Существует вот такой простой компонент для прелоада изображений https://github.com/hzdg/react-imageloader

Есть два макбука в постоянном использовании: Macbook Air 2013 13" i7 8Gb/512Gb и Macbook Pro 2014 13" i5 8Gb/256Gb.

Главный плюс у Macbook Pro - это экран. На него реально приятно смотреть. С любым другим экраном глаза начинают очень быстро уставать, в том числе и после экрана Macbook Air. Это киллер-фича. Второй плюс - есть возможность заказать модель с 16Gb RAM, у Air 8Gb потолок. 16Gb не лишними будут точно.

Air работает дольше, он реально держит заявленное время. Не экономя особо энергию (но и не нагружая тяжёлыми задачами) в режиме web-разработки 10 часов работал спокойно. Если просто сёрфить в интернете, можно выжать и больше заявленных 12 часов. Тестов полно. Pro по ощущениям не дотягивает до заявленных 9 часов при том же профиле использования, но точно не замерял, поэтому врать не буду.

Pro на много сильнее греется, чаще включает вентилятор. Во многих задачах, в которых Air практически холодный, Pro уже заметно тёплый.

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

Нативное разрешение Pro эквивалентно 1280х800 против 1440х900 у Air. Т.е. на экран влезает меньше информации. В настройках есть возможность установить более высокое разрешение, но с ним не всё так гладко. Работает оно, как заявлено, всё хорошо масштабируется, но есть разница в восприятии взглядом. Я не могу точно сказать, что это - результат интерполяции или понижение частоты обновлений, но глаза чувствуют, что что-то не так. Он продолжает выглядеть на много лучше чем Air, но если вернуться на нативное разрешение глаза сразу "отпускает". Долго пробовал работать на масштабированном экране (зрение вроде позволяет), но в итоге вернулся к нативному.

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

Не смотря на все недостатки Pro по сравнению с Air в основном использую именно его, т.к. экран затмевает собой всё остальное.