Как стать автором
Обновить

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

Не совсем понимаю про requestAnimationFrame
У React 16 есть зависимость от requestAnimationFrame. В NodeJS окружении этой функции нет и для нее необходимо написать заглушку.
Но это необходимо только на серверной стороне и в тестовых окружениях?
Почему, в любых окружениях, где это не реализовано. Например в старых браузерах.
Пакет prop-types «15.6.0 is the latest of 17 releases».
Будет 16.0.0 версия или все без проблем работает с этой?

Честно говоря, забивал на варнинги о deprecated :)
С тех пор, как prop-types ушёл в мир иной свой отдельный репозитарий, его версии не совпадали с версиями React. Не знаю точно политики Facebook, но похоже на то, что этот пакет был сделан только для безболезненного удаления его из кодовой базы реакта (эдакие юзер-френдли breaking changes).

У нас с 16-й версией вроде как работает (причём не с 15.6.0, а с какой-то более старой версией), но его почти не осталось — везде перешли на flow-аннотации. Чего и вам советую :)
Понятно. Почитаю что это такое :) Оно ведь? flow.org
Оно) Раз вы не читали про Flow, то рекомендую перевод товарища m1rko: habrahabr.ru/post/326394
Как именно используете flow внутри react-компонентов? Мы используем babel-flow-plugin-proptypes
Мы вообще отказались от propTypes. У нас практически везде functional stateless components, в этом случае пропсы приходят как аргумент компонента-функции, соответственно мы просто пишем аннотацию:
const SomeComponent = (props: SomeComponentProps) => {}

В случае stateful c наследованием от обычного React.Component используем стандартный синтаксис flow:
class PromoList extends React.Component<PromoListProps> {}

Нигде не преобразовываем в prop-types, поэтому отключили соответствующее правило в eslint-плагине react/prop-types.
Или сразу на typescript — можно будет получать сообщения мгновенно через language server, а не постпроцессом на сохранение файла.
Не работал с typescript, не могу сказать как он в сравнении с flow, но последний тоже использует language server и позволяет получать сообщения об ошибках прямо во время написания кода.
Ну тогда они проделали хорошую работу за последний год, раньше flow работал только под osx и только как обработка сохраненного файла. Но в случае с ts мы можем избавиться от babel-я (а в случае с flow мы принуждаем к его использованию) и гнать код напрямую в нужный таргет (включая jsx и декораторы) и в нужном формате (commonjs, umd). Так же получаем приятные необязательные вещи типа контрактов-интерфейсов, модификаторов доступа и enum-ов.
Flow очень быстро развивается сейчас, много изменений, фиксов и релизов. А с декораторами да, беда у babel, поддержка актуальной спеки декораторов появилась только в babel@7, который пока бета.

А остальное тоже есть, просто ts использует встроенные возможности, а в случае c flow надо использовать россыпь инструментов (что нисколько не пугает, видимо потому, что привык уже). Интерфейсы были давно, точно больше года назад, да и энамы тоже. И модификаторы доступа появились во flow, кстати, пусть и недавно :)

Надеюсь это не превратится в холивар, а останется обменом мнениями между двумя коллегами :) И я с удовольствием попробую typescript в живом коммерческом проекте, если представиться такая возможность. Как и на dart вернуться было бы интересно, просто для саморазвития.
Россыпь — это утомительно для настройки нескольких проектов. :( Раньше использовали jsdoc + webstorm на бэкенде, переехали на ts + vscode — пока только один позитив как по фичам, так и по скорости работы. Про холивар — а есть тема для него? То, что есть конкуренция — так это замечательно, стимулирует развитие всех продуктов :)
НЛО прилетело и опубликовало эту надпись здесь
Да, вы правы, грешным делом подумал, что уже имплементировали private полностью (впрочем к protected ещё не приступали вообще). А для private есть только поля, но не методы. По методам ждут соответствующего предложения в TC39, которое пока на stage-2, а поля уже в stage-3 и появились в flow@0.54.0 (последняя версия — 0.56.0).

Есть ещё read-only (и write-only модификаторы вдобавок) в интерфейсах, которые воспроизводят функционал ключевого слова final.

А перечисления живут и здравствуют:
const countries = {
  US: "United States",
  IT: "Italy",
  FR: "France"
};

type Country = $Keys<typeof countries>;

const italy: Country = 'IT';
const nope: Country = 'nope'; // ERROR TROWN
Поддержка произвольных DOM-атрибутов. Читается со слезами на глазах…
Вам не понравилось качество перевода или возмущает, что React наконец перестали «помогать» разработчикам спасаться от левых ДОМ-атрибутов?)
Это слёзы счастья.

Обновился. Пока что споткнулся только на двух одинаковых моментах:


  • события вроде onClick не воспринимают false как null или undefined. Т.е. если было что-то вроде onClick={someBoolean && this.onClick}, то теперь придётся как-нибудь иначе написать. Например так onClick={somBoolean ? this.onClick : null}.
  • render метод в reactDOM точно таким же образом реагирует на callback. В моём случае я проглядел этот момент, пока тестировал в dev-сборке, т.к. у меня было dev && someMethod. И поймал я эту ошибку уже в минифицированной версии. Что характерно, теперь ошибки на продакшне идут по номерам и не содержат внятного текста. Его можно получить перейдя по такой вот примерно ссылке. Возможно так и раньше было, но я столкнулся впервые.

В остальном вроде всё работает, как работало.

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

Так было и раньше

А onClick={someBoolean && this.onClick} у вас точно раньше работало?

Чисто теоретически оно вообще не должно работать, если React не будет самостоятельно разбирать выражение. Ведь там вместо биндинга функции происходит просто выполнение логического выражения. Или я что-то не понимаю.

Всегда пользовался вторым вариантом и даже как-то не задумывался.

Работало. И сейчас работает, только warning-и кидает. А что именно вас смущает? Всё что выполняется в {} всегда выполняется, это же просто JavaScript код (посмотрите итоговый js-code и React.createElement). Или вы про this внутри this.onClick? Если про this, то я использую такую нотацию:


class MyComponent extends React.PureComputed 
{
  onClick = evt =>
  { 
    // some code
  }

  // code
}

Что примерно эквивалентно:


constructor()
{
    // some code
    this.onClick = evt => { /* code */ };
}
Блин, да, верно. Все, разобрался. Затупил :)
Удивительное дело — Реакт 16 вышел несколько дней назад. Казалось бы — большое событие во фронтэнде и во всех тематических чатах в телеге уже это обсудили, а вот статей на больших ресурсах на эту тему кроме этой до сих пор не было.
Это настолько большое событие, что об этом трезвонить начали чуть ли не за год на всех фейсбучных конференциях. У меня до сих пор слайды для коллег остались (сделанные по конспекту доклада того же Эндрю Кларка), которые почти полностью повторяют эту статью. Как и в issues на гитхабе реакта многие эти вещи уже обсуждались по много раз. Так что когда я выкладывал этот перевод, вполне допускал мысль, что меня заминусуют с комментариями: «ну и чО ты тут навыкладывал? это давно всем известно уже» :)
Спасибо! Очень интересные слайды!
А подскажите как его подружить с react-hot-loader?

С версией 1.х пишут что не работает (и не работает). Попробовал 3-ю бету — та же ошибка.
Второй версии вроде как не существует.

Или я отстал от жизни и сейчас hot-reload для Реакта делается иначе?
Упс, забыл отписать. У нас react-hot-loader@3.0.0-beta.7 остался, той же версии, которая была ранее. HRM работает и для реакта без каких-либо изменений. Не знаю, про какую ошибку вы говорите.

Вы можете посмотреть, как в react-starter-kit сделали переход на react@16.
Хм. На beta.6 не работало, потом может попробую beta.7, возможно прокатит. Или ошибка «на моей стороне».

Хотя мне третья версия лоадера жутко не нравится. Там только манипуляций добавили, чтоб оно заработало. И самое печальное — обертка приложения в отдельный контейнер.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории