Никита Егоров

В интересующем вас компоненте определяете хук beforeRouteEnter - в нём и инициируете получение данных. Как оно конкретно выглядит - непосредственно выполнение запроса, или вызов экшена - тут вам виднее. После получения данных дёргаете next. Всё.

UPD. Не, не всё. Если не очень поняли, о чём я - сделал небольшой пример. Три роута, первые два ни о чём, последний - показывает данные из хранилища. И при каждом переходе инициирует их обновление.

сложность O(n)

Проходим по массиву только один раз. Для каждого элемента мы записываем разницу между текущим элементом и данной суммой и устанавливаем эту разницу как ключ в объекте. А значением для этого ключа ставим текущий элемент.

const getPairsWithSumFromArr = (arr, sum) => {
    let map = {},
         res = [];

    for (let i=0; i < arr.length; i++) {
        const currEl = arr[i];

        if (map[currEl] !== undefined) {
            res.push([map[currEl], currEl]);
        } else {
            map[sum - currEl] = currEl;
        }
    }

    return res;
}

Почему функция возвращает undifinded?

Потому что функция f синхронно отрабатывает и не возвращает никакого результата.

Как вернуть результат из setInterval?

Можно захардкодить, можно использовать колбек или Promise.
Хардкод:

function f() { 
  setTimeout(console.log, 500, 1);
}

f(); // 1

Колбек:

function f(cb) { 
  setTimeout(cb, 500, 1);
}

f(console.log); // 1

Promise:

function f() {
  return new Promise(resolve => {
    setTimeout(resolve, 500, 1);
  });
}

f().then(console.log); // 1

UPDATE: реальные тестовые задания и разборы здесь, ответы на все вопросы из поста в моем блоге об обучении react.

не включая основы js

Извините, но стандартная задача, про "напишите функуцию add, которая при вызове add(1)(2) вернет 3" - многих положила на лопатки =) Поэтому будьте готовы..

React
0) Какую проблему решает react ?
1) Мгновенно ли срабатывает setState? Если нет, то как выполнить код, который 100% выполнится после того, как новый state будет установлен?
2) Зачем многие постоянно пишут в constructor: this.FUNCTION_NAME = this.FUNCTION_NAME.bind(this) и отсюда вопрос вытекает чему равно this в разных местах вашего компонента...
3) в каких методах жизненого цикла стоит выполнять xhr запросы? В каких стоит "обновлять state на основе props"?
4) Что будет если вызвать this.setState в render методе компонента?
5) зачем нужен componenWIllUnmount, приведите пример..
6) Контролируемые, не контролируемые компоненты
7) Как организовать роутинг в реакт приложении? (ответ: взять react-router - подходит, но было бы круто, если бы вы рассказали, как он примерно работает)*
8) Зачем нужны propTypes? Что происходит с ними в production сборке?
9) Как можно удобно "отлаживать" чужой код приложения, написанного на react (намек в сторону React devtools)
...

Redux
0) Какую проблему решает redux?
1) Зачем многие создают типы действий NAME_REQUEST / NAME_SUCCESS ? А заодно, что такое "действие", а что такое "создатель действия"...
2) Что такое редьюсер? Можете написать простой редьюсер без react/redux?*
3) Для чего нужен redux-thunk? Как он работает? Напишите (можно псевдокод) асинхронный создатель действия (либо, если надоело говорить "терминами" - асинхронный aciton)
4) Как компоненты приложения получают "пропсы" из "стора"?*
5) Можно ли (и считается ли это нормальным) использовать state, если используется Redux?
6) Почему в reducer'ax мы возвращаем новые объекты? Приведите пример, когда вы возвращаете новый объект, а когда тот же самый.
6.5) А так же, "как в js вообще это работает?". Например:

let obj1 { name: 'Test', age: 100 }
let obj2 = obj1
obj2.name = 'Test_new'

Что будет в obj1, почему? В каких случаях объекты могут быть равны?
7) Что возвращает функция connect (из react-redux)?
...

Общее:
0) package.json
1) Webpack, gulp, etc...
2) node.js
3) promise

Что-нибудь практическое:
1) Как бы вы валидировали форму, если ошибки валидации приходят после submit'a ее на сервер..
2) Почему не работает следующий код, сделайте чтобы работало
...
На истину не претендую, но такие вопросы имели место быть на собеседованиях. В беседе можно многое разузнать дополнительными вопросами и так далее. Так же, если часть вопросов вам неизвестна - не беда, многие и на половину ответить не могут.

p.s. возможно дополню...
p.p.s. звездочкой отметил, на мой взгляд не самые необходимые для junior-собеседования вопросы.

Хороший кандидат на должность Junior React Developer, по моему мнению, должен соответствовать следующему перечню требований:
1. Хорошее знание JavaScript. В React разработке используется ES6 и большинство экспериментальных фич еще не вошедших в стандарт.
2. Хорошее знание HTML и CSS. Кроссбраузерная верстка. Так же, хорошо иметь представление о том, что такое css-in-js.
3. Web APIs. Умение работать с объектной моделью документа(DOM) и все эти XMLHttpRequest, localstorage, cookie, history и прочее.
4. Хорошее знание API React. Вы должны хорошо знать React, знать его возможности, понимать основные концепции и уметь ответить на большинство типовых вопросов. Для этого достаточно хорошо изучить документацию, разобрать пару типовых проектов на github и попрактиковаться. Много полезной информации, приёмов и идей можно подчерпнуть из тематических статей и докладов. Так же, на просторах интернета можно найти подборки типовых вопросов, часто задаваемых на собеседованиях. В англоязычном сегменте их больше.
5. Redux. Уверенное знание API. API библиотеки до боли пост. Знать, что такое промежуточное ПО и зачем оно. Понимать базовые концепции архитектуры Flux. Все это есть в документации и многочисленных курсах.
6. Умение работать с менеджером пакетов npm на базовом уровне.
7. Node.js. Хотя бы уметь написать простейший express/koa сервер, который будет отдавать ваше приложение и статику.
8. Webpack. Базовые знания.
9. Умение работать с git. Хотя бы знать и уметь примерять команды: init, clone, add, commit, push, pull, merge, checkout.
10. Иммутабельность. Четкое понимание зачем это надо. Знание приемов иммутабельного изменения структур данных. Это есть в официальном туториале React.
11. Статическая типизация TypeScrpt/Flow. Для начала хватит самых основ и способности понимать чужой код.
12. Функциональное программирование. Хватит знаний полученных в процессе изучения JavaScript, а так же не помешает знать, что такое каррирование, чистые функции и рекурсия.
13. Базовые концепции ООП. Хватит знаний полученных в рамках изучения JavaScript.
14. Асинхронный код. Понимать как его правильно организовывать. Promise, async/await.
15. Сетевые протоколы передачи данных. Вполне хватит базовых знаний о http/https, о том, что такое заголовки и какие они бывают. Хорошо знать о том, что такое websocket.
16. За плечами должен быть хотя бы один учебный проект на React. Хватит типового тестового задания.
Примеры таких заданий: 1, 2, 3(сайт может быть не доступен на территории РФ, советую отрыть через VPN и посмотреть), 4, 5. Если подобного проекта у вас нет, то будьте готовы, что потенциальный работодатель предложит вам выполнить тестовое задание и только по его результату вас, может быть, пригласят на техническое интервью. Если напишите хорошо, вас скорей всего пригласят.
17. Желателен опыт создания типовых UI элементов. Например, чтобы не вызывало трудностей написать простой кастомный чекбокс. Куча примеров реализаций типовых элементов есть на codepen.

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

Похожий вопрос.

Смешались в кучу кони, люди...

ООП нужен для управления сложностью.
В простых проектах он только вносит лишний головняк в плане проектирования, но в сложных - позволяет разделять огромную ужасную бизнес-логику на какие-то отдельные блоки/модули/классы с которыми можно работать не пытаясь затолкать в голову весь проект.
Вот я юзаю метод Billng.getUserBalance() и не задумываюсь что там внутри этого getUserBalance()
может там чтение из файла, или запрос к базе данных, или может лазером посылают сигнал на луну - меня не волнует, мне только циферка нужна.

Паттерны (шаблоны проектирования же) нужны для того, чтобы объяснить ДРУГИМ ПРОГРАММИСТАМ что за хрень мы тут написали.
Можно писать код, который вообще ни на что не похож и не соответствует никаким шаблонам. И тем людям, которые захотят разобраться в коде вынуждены будут его прочесть целиком и осмыслить. Или мы пишем: здесь у нас шаблон "наблюдатель" а вот нам у нас singleton и всем сразу понятен общий смысл.

С MVC пример не особо удачный. Дело в том, что сейчас существует довольно много разных штук на которые почему-то прилепили буковки MVC, хотя на самом деле... В целом понятно, что вы пишете о случае с "толстыми контроллерами" но ведь может быть несколько разных контроллеров которые работают с одной моделью.
И могут быть разные модели, отдающие данные в одно и то-же представление. Но об этом ниже.

И с полиморфизмом вы что-то напутали. Посмотрите хоть в википедии что это и зачем. Клиентов ведь может быть больше одного. Сегодня наш код работает на телефоне с ios, завтра на andoid'е, а послезавтра на голографическом телевизоре с пси-управлением. И данные он вчера брал из MSSQL а сегодня берет из mongodb. Но при этом у нас все круто спроектировано, и мы не меняем ядро приложения. Только подсовываем новые реализации интерфейсов по необходимости. Вот про что полиморфизм.

Так:

img {
  filter: hue-rotate(180deg) saturate(10);
}

??

Если в объекте используется всего 1 событие (или все события допустимо обрабатывать одним обработчиком), то можно обойтись без bind и прочих хитростей по сохранению контекста:

class ProgressBar {
    constructor(wrapper, line) {
    	this.wrapper = wrapper;
        this.line    = line;

        // передаем объект а не функцию оО
    	wrapper.addEventListener('mousemove', this);
        wrapper.removeEventListener('mousemove', this);
    }

    // что бы использовать объект в качестве слушателя,
    // у него должен быть метод handleEvent - именно он будет получать события
    handleEvent(event) {
    	this.line.style.width = event.clientX + 'px'
    }
}

https://developer.mozilla.org/ru/docs/Web/API/Even...

Байнд создаёт новую функцию, а удаляете вы старую. Вынесите байндинг в отдельную переменную и передайте в *EvenListener её.

Array.from(document.querySelectorAll('.dropdown-trigger'), el => el.dataset.target);

<span>Привет</span>, как дела?

span {
  letter-spacing: .2em;
  margin-right: -.2em;
}

Во-первых, гипотеза лингвистической относительности утверждает, что чем больше языков знаешь, тем гибче и богаче твой логический аппарат. По своему опыту могу сказать, что это правда. Например изучение Lisp'ов существенно расширило мои возможности в других языках. Но мой опыт и мнение не так авторитетны, как авторов всемирно известного бестселлера "Программист-прагматик" - Эндрю Ханта и Дэвида Томаса, которые пишут: «Изучайте по крайней мере один новый язык ежегодно. Разные языки решают одни и те же проблемы разными способами. Изучив несколько разных подходов, вы сможете расширить свой кругозор и не погрязнуть в рутине.»

Во-вторых, рано или поздно профессиональный рост java-программиста, например, неизбежно приводит его к необходимости глубоко понимать работу компилятора и виртуальной машины, а это невозможно без знания C++, на котором они написаны.

В-третьих, java-программист свободно лазающий за ответами в исходники JVM, способный дебажить сборщик мусора, писать JNI-библиотеки и использовать Compiler API для метапрограммирования имеет больше предложений работы и более выгодные условия.

Как Вы думаете, как бы написал опытный реакт-разработчик...

Я конечно таковым ни разу не являюсь, но всё-таки скажу пару слов.

проверки через тернарный оператор внутри render?

Это окей - conditional rendering.

render() {
    const paths = [

Из метода render массив paths следует убрать. Может быть, его даже стоит сделать параметром компонента.

onClick={ () => {this.setState({isOpen: !this.state.isOpen})} }

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

this.props.history.listen(...

Если предполагается, что во время работы приложения экземпляр компонента будет создаваться несколько раз, то при удалении экземпляра надо снимать обработчик, иначе вывод в консоль задвоится (затроится, зачетверится,...). Сделать это несложно - listen возвращает функцию, снимающую обработчик, так что:

componentWillMount() {
  this.unlisten = this.props.history.listen(...

componentWillUnmount() {
  this.unlisten();

<Link className="next_btn"...
<Link className="prev_btn"...
Выглядят подозрительно похожими. Я бы рассмотрел вариант сделать под них отдельный компонент, который бы получал isOpen и свойства объектов paths[currPathIndex +/- 1] в качестве параметров.

1. Статические данные. Зачем они определяются каждый render? Их можно вынести за пределы компонента:

const paths = [ ... ];
class Menu extends Component { ... }

А по-хорошему генерировать роуты и переключать страницы по одним и тем же данным:

import routes from './routes';

/* ... */

<Switch>
  {routes.map(route => (
    <Route
      exact={route.isExact}
      path={route.path}
      component={route.component}
    />
  )}
</Switch>

2. По какой логике используете ключевые слова const и let? Используйте const для всех переменных которые не переопределяются в коде, а let только для тех, которые переопределяются. Это заметно снижает когнитивную нагрузку с читающего код.

3. Конструкции вроде:

let
  isPrev = currPathIndex !== 0,
  isNext = currPathIndex !== paths.length - 1;

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

const hasPrev = currPathIndex !== 0;  // (1)
const hasNext = currPathIndex !== paths.length - 1; // (2)

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

(1), (2) - обратите внимание, что я заменил префикс is на has, что правильней. Для булевых переменных помимо is, можно использовать следующие префиксы is, has, should и подобные. Примеры:

isVisible
hasChildren
shouldShowCloseButton

4. Если используете много ключей из state и props можно сделать деструктуризацию:
const { isOpen } = this.state;

5. Don't repeat yourself. Код который вы используете многократно старайтесь выносить в отдельные компоненты:

<Link className="next_btn" style={ this.state.isOpen ? {visibility: 'hidden'} : null} to={paths[currPathIndex + 1].link}>
  <span>{ paths[currPathIndex + 1].title }</span>
</Link>

Его можно переписать компонентом с примерно таким интерфейсом:

<NavButton prev isVisible={!isOpen} path={prevPath} />

6. Зачем тернарки там где лучше подойдет &&?

{isOpen && this.renderСloseBtn()} // (1)
{hasPrev && <NavButton prev isVisible={!isOpen} path={prevPath} />}
{hasNext && <NavButton next isVisible={!isOpen} path={nextPath} />}

(1) - обратите внимание, что рендер кнопки вынесен в отдельный метод, так она будет создаваться только тогда, когда она нужна. В вашем же коде она определяется даже тогда когда не добавляется на страницу.

Используйте тернарный оператор в render, там где есть альтернативный вариант:

{isFetching ? <Preloader /> : <Content data={data} />}

Но не используйте вложенных:

{isSignedIn ? isMobile ? <UserMenuMobile /> :  <UserMenuDesktop /> : <MainMenu /> }

Лучше так:

{isSignedIn ? this.renderUserMenu() : <MainMenu /> }

где this.renderUserMenu:

renderUserMenu() {
  return this.props.isMobile ? <UserMenuMobile /> :  <UserMenuDesktop />;
}

7. Старайтесь не писать избыточных конструкций:

class Menu extends Component {
  constructor(props) {
    super(props);
      this.state = {
          isOpen: false,
      };
  }
}

При использовании прессета stage-0, create-react-app, jsfiddle и прочих библиотек/бойлерплейтов/сервисов, использующих плагин babel-plugin-transform-class-properties, достаточно:

class Menu extends Component {
  state = {
     isOpen: false,
  };
}