@ElianL30 янв 2015 в 10:09

Flux для глупых людей

6 мин

266K

JavaScript * ReactJS *

Туториал

Перевод

+31

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

@veitmen 30 янв 2015 в 12:23

Спасибо, все структурировалось в моей голове.

Вся соль, в функции Render и в том, что state — это не часть компонента, как мне кажется. Вот именно это место и полностью мне объяснило всю соль flux. Еще раз спасибо.

@veitmen 30 янв 2015 в 12:29

Но, насколько я понимаю, выносим за пределы компонента только то состояние, те данные, которые необходимо изменять на сервере.

И да, PS в статье я прочитал. :)

@ElianL 30 янв 2015 в 12:36

state все таки относится именно к компоненту, и именно state однозначно определяет как будет отрисован компонент.
За пределы мы выносим не state, а данные, и в нужный момент просто копируем эти данные(из store) в state

@veitmen 30 янв 2015 в 13:23

Да, запутался я в терминах. И данные и state под одну гребенку запихал. Перечитал свой коммент, понял, что написано не то, что я хотел сказать. И да, Вы абсолютно правы.

@kossnocorp 3 фев 2015 в 05:51

Вы хотели сказать props вместо state.

@ElianL 3 фев 2015 в 08:19

нет, я хотел сказать, именно, state. props это список параметров пришедших в компонент из вне(от родителя), а state набор параметров описывающий именно внутренее состояние компоненета

@DmitryOlkhovoi 24 окт 2015 в 15:22

А вот и зря вы используете state. Flux создан для предотвращения непонятных изменений данных, и именно благодаря props мы можем декларативно объявлять компоненты и обновлять их основываясь на данных которые хранятся ВНЕ компонента. Тем самым имя куда более предсказуемые и чистые функции, нежели с каким-то магическим внутренним состоянием

@DmitryOlkhovoi 24 окт 2015 в 15:59

state должен использоваться на контрольной вьюхе, а ниже спускаться только за счет пропсов. Хотя возможно вы просто запутали понятия вью, компонент и контрол-вью))

@veitmen 30 янв 2015 в 12:25

Кстати, я ошибаюсь, или подход с тем, что мы не следим за тем, как именно изменился State возможен только в ReactJS, за счет виртуального DOM'a?

Точнее можно везде делать полную перерисовку, но только ReactJS позволяет это делать без просадки рендеринга.

@ElianL 30 янв 2015 в 12:34

Скорее так, React полностью «перерисовывает» только виртуальный DOM, а реальный DOM трогаем по минимуму.

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

@veitmen 30 янв 2015 в 13:24

Да, я понимаю. Я и хотел сказать, что только в ReactJs, на текущий момент, можно делать реализацию, которая не зависит от того, как именно изменился state. Точнее я хотел уточнить, только ReactJs позволяет так делать?

@Bright 30 янв 2015 в 13:32

Стоит ещё заглянуть в комментарии к оригинальной статье, там разработчики из фэйсбука отвечают на некоторые вопросы:
blog.andrewray.me/flux-for-stupid-people/#comment-1819956843

@PQR 30 янв 2015 в 17:51

Да, комментарии стоящие.
Позволю себе перевести один из них.

Я работаю над Atlas в Facebook и использую React+Flux уже полтора года, так что могу ответить на некоторые вопросы:

— Как отправлять данные на сервер и обратно?

Отправка данных на сервер: Action Creator делает асинхронный запрос к серверу и, как только получен success или failure результат, посылает Action с соотвествующей информацией в Dispatcher, а затем обновляются и Store. Впрочем, Action Creator может послать Action не дожидаясь ответа от сервера, предполагая оптимистичный исход.

Получение данных от сервера: когда вы запрашиваете данные из Store, он может начать загружать данные в бекграунде и проинформировать вас, как только они получены. Store может быть синхронным, в этом случае getBlah() возвращает null если данные не были загружены, или асинхронным, тогда getBlah() возвращает Promise.

— Как управлять связью между компонентами не имеющими общего родителя?

Используйте Actions и Stores — они глобальны и могут использоваться любыми компонентами.

@PQR 31 янв 2015 в 19:45

Ещё один стоящий комментарий, на этот раз из facebook/flux репозитория на github:

Пример чат-приложения я подготовил специально для конференции ForwardJS осенью 2014 года…

… мы хотели показать вызов серверного API из Action Creators, как это предпочитает делать Jing (автор Flux). Однако, внутри FB многие обычно делают запросы к серверу непосредственно из Store. Я считаю оба эти способа корректыми и не отдаю предпочтения какому либо из них.

Одно из преимуществ обращаться к серверу в Action Creator, а не в Store, это обработка ошибок.

@GearHead 30 янв 2015 в 16:36

Сложилось впечатление, что фейсбуковцы переизобрели велосипед. Посмотрите на подход рендеринга Ember.js или динамический рендеринг Joosy. Он делает абсолютно то же самое, только прозрачно для пользователя: bind и dispatch магически происходят внутри фреймворков.
Единственный принципиальный плюс в решении от FB — это рендеринг через React с виртуальным DOM, и тот под глубоким сомнением. Насколько реально широк тот кейс, когда данные меняются, но не меняется отображение? И реально ли такая оптимизация _заметна_ пользователю, или её можно заметить только профайлером?

@azproduction 30 янв 2015 в 21:33

Из-за декларативности компонент/шаблонов React выигрыш огромен. Вам не нужно определять все состояния компонента и переходы между ними. При увеличении сложности это значительно упрощает поддержку.

@lolmaus 31 янв 2015 в 15:54

Чем шаблоны React декларативнее шаблонов Ember?

Чтобы не быть голословным, я взял пример кода "A Stateful Component" с официального сайта React и реализовал его на Ember: emberjs.jsbin.com/figobe/edit?js,output Как видите, всё то же самое, только на два года раньше, чем React. ;)

React я не пробовал, но полагаю, что двусторонний data-binding и самовычисляемые свойства (computed properties, аналог нативных `get` и `set`, но со встроенным кешированием и автоматическим пересчитыванием при изменении зависимых свойств) избавляют от необходимости писать массу вспомогательного кода, который приходится писать в React.

Я уже не говорю про то, что если вы выбрали React, вам нужно самому позаботиться о Model, Controller, Router, Adapter и т. д… Код, соответствующий указанным слоям, есть в каждом приложении, просто не везде он вынесен в самостоятельные сущности. В лучем случае, вы надергаете зоопарк разнообразных библиотек и будете жирно смазывать их glue code'ом, чтобы заставить их работать друг с другом. В худшем, будете изобретать велосипеды.

@lolmaus 31 янв 2015 в 18:17

Посмотрел следующий пример с офсайта React:

  render: function() {
    var createItem = function(itemText) {
      return <li>{itemText}</li>;
    };
    return <ul>{this.props.items.map(createItem)}</ul>;
  }

В Ember это выглядело бы так:

<ul>
  {{#each item in items}}
    <li>{{item}}</li>
  {{/each}}
</ul>

Как говорится, без комментариев.

Я уже не говорю о том, что объявлять функцию внутри функции — это не очень хороший стиль программирования. Не ожидал такое увидеть на титульной странице флагманского open source продукта Facebook. :P

@imater 31 янв 2015 в 18:22

У вас другая вера.

@asci 1 фев 2015 в 09:26

>>объявлять функцию внутри функции — это не очень хороший стиль программирования
вы точно про JS говорите?

@lolmaus 1 фев 2015 в 10:40

Единственный разумный повод объявлять функцию внутри функции — это создать замыкание или ограничить scope. В данном случае не происходит ни того, ни другого.

Это:

  render: function() {
    var createItem = function(itemText) {
      return <li>{itemText}</li>;
    };
    return <ul>{this.props.items.map(createItem)}</ul>;
  }

следовало записать так:

  createItem: function(itemText) {
    return <li>{itemText}</li>;
  },
  render: function() {
    return <ul>{this.props.items.map(this.createItem)}</ul>;
  }

Я тут протестировал, разница в производительности — двукратная: jsperf.com/sibling-functions-vs-nested-functions

Не говоря уже о разнице в сложности структуры кода (и, соответственно, читаемости), а также наличии/отсутствии возможности юнит-тестирования функции createItem.

@asci 1 фев 2015 в 15:12

Ну как минимум замыканий достаточно для того, чтобы не говорить что объявлять функции внутри функций — не очень хороший стиль программирования.

Что же до того, как записан код в примере, предполагаю, что так сделано намеренно, ибо это позволяет держать под контролем (в поле зрения) доступные для рендера функции внутри одного скоупа, и не смешивать с остальными методами вьюшки, что улучшает «понимаемость»

А за тест спасибо, возьму на вооружение

@asci 1 фев 2015 в 09:29

Да, клево, выглядит короче. Но все портит магия эмбера. Когда пробрасываются контексты их родительских контроллеров\вьюх\роутеров, и понять откуда появилась конкретная переменная — нет никакой возможности. Даже если дебажить — цикл рендера эмбера превращает дебаг в ад.

@lolmaus 1 фев 2015 в 10:43

В современном Ember вместо Views и Controllers используются Components, которые имеют сугубо изолированный scope.

@asci 1 фев 2015 в 15:16

Так этот современный эмбер уже вышел или нет? Так-то компоненты были и до 2й версии, и ими я хоть как-то мог осмысленно пользоваться среди ужаса и боли наследованных\перенаследованных скоупов

@lolmaus 15 фев 2015 в 11:59

Единственное, чего еще нет, это возможности из route передавать управление сразу в component, минуя view и controller. Эта возможность запланирована на версию 1.12 (недавно вышли 1.10 и 1.11beta).

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

@So1 24 мар 2015 в 08:27

объявлять функцию внутри функции — это не очень хороший стиль программирования

Можно поподробней? Например:

def joinPaths(*args):
    
    def preparePathPart(part): # prepare path parts to be joined by join method
         # trim slashes from the end
         # etc

    def joinParts(paths, delimiter='/'): # another function inside of a function, join works only with prepared data
         return args.join(delimiter)

    return joinParts( map(args, preparePathPart) )

>>> joinPaths('/etc/', 'init.d/', 'some.conf')
'/etc/init.d/some.conf'

P.S. это просто синтетический пример на python-like псевдо-языке
Я не понимаю, какие конкретно могуть быть проблемы с тем, что я тут использовал аж 2 функции внутри joinPaths

Ровно то же самое я делаю не только на Python, но и на PHP/JS/Ruby/Go. Ни у меня, ни у моих коллег за долгие годы не было с этим никаких проблем. Более того, я считаю, что такая внутренняя декомпозиция хорошо структурирует функцию внутри самой функции. Неплохо было бы увидеть хорошее объяснение, почему это плохой стиль.

@lega 24 мар 2015 в 09:04

Кстати по коду может показаться, что вложенные ф-ии создаются при каждом запуске joinPaths, хотя в действительности этого не происходит (в случае с питоном), вложенные ф-ии уже «скомпилированы» до этого, к ним просто применяются разные «замкнутые» переменные, поэтому такой подход не должен повлиять на производительность (если кого это волнует).

@lolmaus 24 мар 2015 в 10:04

За Python не скажу, а в JS разница в производительности 15-кратная: jsperf.com/externally-vs-internally-defined-function

@lega 24 мар 2015 в 10:57

Да, в JS видимо не так, зато можно сделать «замыкание», результат как бы тот же — приватные методы, но при этом не теряем производительности: jsperf, у меня оно показывает чуть лучше результат.

@lolmaus 24 мар 2015 в 10:04

Ответил выше.

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

@azproduction 30 янв 2015 в 21:29

Вся суть React в декларативности шаблонов. Компонент при каждом изменении полностью перерисовывается (но виртуально), затем React вычисляет минимально дешевую мутацию состояний из А в Б. В императивном подходе все мутации состояний нужно определять руками. При увеличесии сложности компонента возрастает сложности определения всех состояний и переходов. Соответсвенно возрастает риск ошибки и сложность понимания.