Comments 22
Статья зачёт.
Ремарка по поводу
class App extends Component {
  render() {
    return (
      <div>
        <Navbar>
          <Navbar.Header>
            <Navbar.Brand>
              <span>Hello World</span>
            </Navbar.Brand>
            <Navbar.Toggle />
          </Navbar.Header>
          <Navbar.Collapse>
            <Nav navbar>
              <NavItem>Время</NavItem>
              <NavItem>Счетчики</NavItem>
            </Nav>
          </Navbar.Collapse>
        </Navbar>
        <Grid>
          <HelloWorldPage />
        </Grid>
      </div>
    );
  }
}



На такие конструкции «Navbar.Header» будет ругатся babel если использовать
'transform-react-remove-prop-types',
'transform-react-constant-elements',
'transform-react-inline-elements'
Это поможет webpack в процессе сборки включить только используемую в проекте часть react-bootstrap

Я так понимаю, что tree-shaking в webpack2 как раз этим и занимается. Пока не было возможности проверить

Правильно понимаете, но webpack 2 пока не production-ready.


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

Занимается, но не путайте мягкое с теплым. Одно дело — максимально уменьшить размер bundle, там где архитектура пострадала (не разнесли модули по файлам). Другое дело — специально делать плохую архитектуру.

Не вижу разницы. Я считаю, что если технология позволяет так делать, то я буду писать


import { Grid, Nav, Navbar, NavItem } from 'react-bootstrap';

вместо


import Grid  from 'react-bootstrap/lib/Grid';
import Nav from 'react-bootstrap/lib/Nav';
import Navbar from 'react-bootstrap/lib/Navbar';

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


Если же Вы тянете целиком условные lodash и react-bootstrap из-за пары функций/компонентов, то я как пользователь из Китая с ужасным внешним интернетом сильно страдаю, ведь Ваш JS грузится у меня не 10, а 30 секунд.

Я ж об этом и говорю, если этим занимается tree-shaking, то с выходом webpack2 можно будет так не писать. Просто уточнил, что именно это оно и дает

Размер сборки увеличивается. Но главное, что создается бессмысленный God-object в исходном коде. А конкретно main-файл, в котором будет либо 1000 строчек, либо:
export Grid  from './lib/Grid'

Расскажите, какой вы видите в этом смысл?

Вместо создания бессмысленных index.js файлов можно создать файл-конфиг для таких модулей, и в каждой папке просто добавить файл package.json:


{
  "name": "HelloWorldPage",
  "version": "0.0.0",
  "private": true,
  "main": "./HelloWorldPage.js"
}

index.js не совсем бессмысленные: с течением времени некоторые компоненты могут вырасти в целое семейство компонентов. В этом случае index.js будет экспортировать несколько сущностей.


У меня не сказать чтобы большой опыт, но я в open-source еще не видел проектов или библиотек, в которых практикуют предложенный вами вариант, но спасибо за расширение кругозора — может просто невнимательно или не туда смотрел

Во время поиска возможных ошибок придется заходить в пустые файлы, которые потенциально могут еще и создать проблему в будущем. Говоря про проекты — https://github.com/koistya/react-static-boilerplate/tree/master/components/Button там например везде это используется. Выглядит очень даже удобно.

UFO landed and left these words here

Изоморфизм в математике.


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

Если быть точным, то изоморфизм в теории категорий, что является одним из разделов математики.
Большое спасибо за ваши статьи про JS и React! Очень помогают вникнуть в тему.
Ну вот сразу же могу найти один довольно важный косяк — вы смешиваете умные и презентационные компоненты. Ладно сейчас у вас небольшо компонент и стейт в коннекте не большой, а если это будет пейджа, которая будет принимать много параметров, так еще и reselect использовать? Есть же пример на офф сайте, где используется mapStateToProps и mapDispatchToProps.

Второй момент — зачем добавлять index.js? Чем вам так не угодил импорт? можно назвать например header/Header.js
index.js — лишняя деталь в механизме, о которой придется помнить. Говорю это не в укор, просто правда интересно, зачем такой подход используется в большинстве проектов?

1) Но… я… не смешиваю. Я разделяю: Counter и ReduxCounter. Первый презентационный, второй — умный.
2) С течением времени проект имеет свойство разрастаться.


Сначала у вас Components/Header.jsx, потом вы решаете стили добавить, локализию — и вот у вас же Header.jss и Header.jsl лежат рядом, а потом еще разбить его на несколько, а потом добавить какую-нибудь фичу, которая нужна только в dev и вот у вас уже Header.dev.jsx и Header.prod.jsx. Когда все такие файлы лежат в Components — это не очень хорошо, поэтому вы создаете папку Components/Header, в которую вам приходится складывать все файлы и переписывать все импорты. Зачем? Можно просто ссылаться на Components/Header. Все разработчки из команды видят и понимают, что происходит — это коротко и наглядно. Причем независимо от изменений и усложнений резолвится всегда будет правильно без необходимости вникать в детали, какой именно файл вы импортируете. Думаете об этом как об аналоге инкапсуляции из ООП.

Кажется, эту запись:
connect(mapStateToProps)(ReduxCounter);

Можно написать вот так:
connect(mapStateToProps, ReduxCounter);

https://github.com/reactjs/react-redux/blob/master/src/components/connect.js


Из исходников видно, что второй параметр connect — это mapDispatchToProps, то есть вы можете взять свою функцию dispatch и использовать ее вместо стандартной, поэтому, если честно, я немного сомневаюсь, что можно написать так, как вы предложили :)

Only those users with full accounts are able to leave comments. Log in, please.