yury-dymov 21 сен 2016 в 10:36

React.js: собираем с нуля изоморфное / универсальное приложение. Часть 2: добавляем bootstrap, страницы и роутинг

21 мин

84K

Node.JS*ReactJS*

Туториал

+23

Комментарии 22

BoryaMogila 21 сен 2016 в 10:55

Статья зачёт.
Ремарка по поводу

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'

Dreyk 21 сен 2016 в 11:34

Это поможет webpack в процессе сборки включить только используемую в проекте часть react-bootstrap

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

yury-dymov 21 сен 2016 в 11:47

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

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

alibertino 21 сен 2016 в 12:16

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

Dreyk 21 сен 2016 в 12:20

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

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';

yury-dymov 21 сен 2016 в 12:26

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

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

Dreyk 21 сен 2016 в 12:29

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

alibertino 21 сен 2016 в 12:39

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

export Grid  from './lib/Grid'

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

reactoranime 21 сен 2016 в 11:45

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

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

yury-dymov 21 сен 2016 в 11:52

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

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

reactoranime 21 сен 2016 в 11:59

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

yury-dymov 21 сен 2016 в 12:06

Спасибо за дополнение

НЛО прилетело и опубликовало эту надпись здесь

xGromMx 21 сен 2016 в 12:11

Не изоморфное, а универсальное. Изоморфизм в ФП

-1

yury-dymov 21 сен 2016 в 12:15

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

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

xGromMx 21 сен 2016 в 12:18

Если быть точным, то изоморфизм в теории категорий, что является одним из разделов математики.

h742220 22 сен 2016 в 06:42

Flux и Redux уже давно умерли. Нужно пользоваться MobX

paratagas 22 сен 2016 в 22:00

Большое спасибо за ваши статьи про JS и React! Очень помогают вникнуть в тему.

Legolas_nsk 23 сен 2016 в 16:41

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

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

yury-dymov 23 сен 2016 в 16:50

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

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

heel 28 сен 2016 в 00:30

Кажется, эту запись:

connect(mapStateToProps)(ReduxCounter);

Можно написать вот так:

connect(mapStateToProps, ReduxCounter);

yury-dymov 28 сен 2016 в 07:55

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

React.js: собираем с нуля изоморфное / универсальное приложение. Часть 2: добавляем bootstrap, страницы и роутинг

Комментарии 22

Публикации

Истории