Антон Спирин

Tree shaking (встряхивание дерева) — термин объединения модулей JavaScript, обозначающий статический анализ всего импортированного кода и исключение того, что на самом деле не используется.

Для более прямолинейной аналогии рассмотрим живое дерево. Дерево встряхивается, и это заставляет мертвые листья отваливаться, оставляя только живые. В основе tree shaking лежит концепция живого включения кода (live code inclusion): мы включаем части, необходимые для начала, в отличие от удаления ненужных частей в конце — устранения «мертвого кода» (dead code elimination).

Tree shaking зависит от import и export модулей ES2015. Выражения import и export составляют статическую структуру модуля приложения. Когда модули объединяются для развертывания приложения, tree shaker анализирует статическую структуру модуля, чтобы исключить неиспользуемый экспорт, уменьшив размер окончательного пакета.

ES2015 позволяет указывать явный импорт. Например, вместо импорта всей библиотеки RxJS мы можем импортировать именно то, что хотим:

import { BehaviorSubject } from 'rxjs/BehaviorSubject';

Это отличается от динамического выражения require, используемого CommonJS или AMD. Tree shaking использует этот принцип для перемещения по зависимостям и исключения ненужных зависимостей для уменьшения размера приложения.

Принцип tree shaking не нов, но он только недавно был популяризирован с помощью сборщика rollup.js, объединяющего модули приложения. Webpack 2 также использует tree shaking. Концепция tree shaking также распространена в Angular с компиляцией AOT.

Источник

Для того, чтобы начать изучение, возможно, хватит. Подтяните ES6 и промисы.
Для того, чтобы написать полноценное, поддерживаемое SPA основ JS и изучения React в кратчайшие сроки, скорей всего не хватит.

Я так же, в свое время, JavaScript параллельно с Backbone изучал. Надо было в кратчайшие сроки начать писать приложение и меня выдернули из мобильной разработки. Так вышло, что навсегда.)

class ArrowUp extends Component {
  state = {
    isVisible: false,
  };

  componentDidMount() {
    window.addEventListener('scroll', this.handleScroll);
  }

  componentWillUnmount() {
    window.removeEventListener('scroll', this.handleScroll);
  }

  handleScroll = () => {
    if (window.scrollY >= SOME_VALUE  && !this.state.isVisible) {
      this.setState({ isVisible: true });
    } else if (window.scrollY < SOME_VALUE && this.state.isVisible) {
      this.setState({ isVisible: false });
    }
  };

  render() { /* ... */ }
}

Проще некуда:
element.scrollIntoView();
Демо

В имплементации React как-то так:

handleLinkClick = e => {
  e.preventDefault();
  const element = document.getElementById(e.target.href);
  element.scrollIntoView();
};

Храните все состояние формы в родителе и передавайте ребенку колбек:

class Child extends Component {
  render() {
    const { handleChange } = this.props;

    return (
      <Wrapper>
        <SomeInput onChange={handleChange} /> 
      </Wrapper>
    );
  }
}

примерный код колбека:

handleChange = e => {
  const { name, value } = this.props;

  this.setState({ [name]: value }, this.calculate);
};

Есть два хороших подхода к организации кодовой базы, которые подходят для большинства проектов: File Type First и Feature First:

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

Дата мапперы в зависимости от задач можно использовать в редьюсерах, в mapStateToProps и asyncActions. Главное чтобы по проекту все было стандартизировано.
В mapStateToProps пишут преобразования необходимые лишь для одного компонента.

Большое количество бойлерплейта это плата которую вы платите за использование redux. Можно писать все константы и редьюсеры руками, можно использовать библиотеки вроде redux-actions и ей подобные. В первом случае вы получаете плюс к гибкости, читаемости и статическому анализу, во втором меньше кода. Я в большинстве проектов предпочитаю первый вариант. Так же создаю шаблоны файлов в Webstorm для asyncActions, contstraints, редьюсера, страницы, компонента и законнекченого компонента.
В специфичных проектах с множеством CRUD запросов и похожих сущностей есть смысл написать CRUD Boilerpalte.

Ошибка не при отдаче html файла. Он без проблем отдается. Во втором случае проблемы со статикой. express.static это middleware(промежуточное ПО). Express все запросы обрабатывает по-порядку через все middleware пока не найдет подходящий endpoint. В первом случае express.static обрабатывает пути до роутера, перехватывая только запросы за статическими файлами и возвращая файлы в ответ. Во втором случае эти запросы попадают в роутер, который у вас обрабатывает все пути и возвращает index.html. До express.static запросы не доходят и вместо всей статики вы получаете этот файл и парсер JS выдает ошибку.

Простой пример:

app.use((req, res, next) => {
  console.log('Time: ', Date.now());
  next();
});
app.use(express.static(__dirname + '/public'));
app.get("/about", (req, res) => { /* */}); // ( 1 )
app.get("/home", (req, res) => { /* */});  // ( 2 )
app.get("*", (req, res) => { /* */}); // ( 3 )
app.get("/never", (req, res) => { /* */}); // ( 4 )

Допустим приходит 4 запроса:

GET https://site/public/img/1.png
GET https://site/home
GET https://site/feed
GET https://site/never

Во всех случаях в консоли покажется: Time: <текущее время>
Первый запрос будет перехвачен express.static и не дойдет до роутера.
Второй запрос будет перехвачен эндпоинтом ( 2 ), ( 1 ) будет пропущен так как пути не совпадают.
Третий эндпоинтом ( 3 ), так как он перехватывает абсолютно все запросы которые до него доходят, ( 1 ) и ( 2 ) соответственно пропущены.
Четвертый запрос так же будет перехвачен и обработан эндпоинтом ( 3 )
До эндпоинта ( 4 ) запросы дойти не могут. Его надо поменять местами с ( 3 )

function invertTree(tree) {
  let { left, right, ...rest } = tree;
  [ left, right ] = [ right, left ];

  return { left, right, ...rest };
}

или:

const invertTree = ({ left, right, ...rest }) => ({ left: right, right: left,  ...rest });

container.innerHTML += "<br />";
Во время этого вызова происходит преобразование innerHTML в строку, конкатенация, удаление всех потомков узла container, анализ получившейся строки и создание новых элементов-потомков.
Так как все элементы узла container заменяются новыми, то слушатели, которые вы вешали на потомков узла до вызова, естественно, не сохраняются.
Можно заменить на:

var br = document.createElement('br');      
container.appendChild(br);

Возможно, в конфиге webpack не прописан public path:

module.exports = {
    ...
    output: {
        publicPath: '/'
    }
}

Правильный путь:
to={`/dictionary/${item.toLowerCase()}`}

shape-outside

can-i-use

Promise.all(data).then(console.log);

{this.props.massMedia.map(item => {
  const type = mediaType.find(el => el.id === item.type);

  return (
    <TableRow key={item.id} directory={item} directory1={type} />
  );
})}