@olegshilov9 июл 2015 в 13:30

React на ES6+

5 мин

72K

JavaScript * ReactJS * Веб-разработка *

Перевод

+16

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

@xamd 9 июл 2015 в 18:24

Так приятно, когда ты читаешь о том, что уже крутится у тебя в продакшене :)

@FractalizeR 10 июл 2015 в 07:21

Спасибо за статью. Подскажите, как вы решили вопрос с отсутствием возможности использовать миксины в определении классов React компонентов? Или просто отказались от миксинов?

@ElianL 10 июл 2015 в 08:52

Один из способов заменить миксины — использовать декораторы. Декораторами так же можно подмешивать в класс какие-нибудь методы.

Правда чтобы подмешивать несколько так называемых «lifecycle methods» уже придется повозиться. Сам решения не видел, но слышал что на просторах интернета уже есть много реализаций.

@ElianL 10 июл 2015 в 08:57

Я представляю себе реализацию примерно следующей.
Декоратор проверяет если в прототипе (например) метод componentWillMount. Если нет, то просто добавляет. Если есть то добавляет свой внутри которого уже вызывается существующий

@FractalizeR 10 июл 2015 в 09:29

Проблема в том, что декораторы не являются утвержденным стандартном… Это ведь ES7, если не ошибаюсь. Хотя внедрение поддержки уже начато многими библиотеками. Babel поддерживает, например. Но в экспериментальном порядке:

These proposals are subject to change so use with extreme caution. Babel may update without warning in order to track spec changes.

@ElianL 10 июл 2015 в 09:34

Верное замечание, этого пока не в стандарте)

Но допустим static методы так же не утверждены, и не вошли в ES6. Но в этой статье описаны. Так что, думаю, и декораторы заслуживают внимания уже сегодня.

@dfuse 8 авг 2015 в 22:48

Статик есть в TypeScript в примерно таком виде, так что думаю и в стандарт рано или поздно проберется.

@hell0w0rd 10 июл 2015 в 11:11

А не получится отключить babel никогда. У нас всегда будет как минимум JSX.

@FractalizeR 10 июл 2015 в 11:51

Я к этому, в общем-то, и не стремился :) Проблема в том, что когда вы используете возможности из разряда нестандартизированных и экспериментальных, а кодовая база проекта велика, при внесенении в стандарт существенных изменений, вы гарантировано получите геморрой. Babel будет изменен так, чтобы соответствовать новым изменениям. А вам придется поменять код, который от них зависит.

@hell0w0rd 10 июл 2015 в 16:55

Такое неизбежно будет происходить с различными инструментами. Другое дело, что есть понятие BC. И если фича существовала год, ее скорее всего оставят с флагом «не поддерживается», или еще что-то подобное. В конце концов всегда есть возможность написания плагинов, или фиксирования версии babel.
Ну и про JSX я упомянул не случайно, он скорее всего никогда не станет стандратом.