Спасибо, так стало понятнее.
Не очень ясно, почему type refinements неправильно отрабатывает конкретно здесь, но в целом проблемы такого рода не так редки, как хотелось бы.
FGJ, у TS с его type guards такие проблемы тоже есть (может, не этом конкретном случае, но на каком-то другом).
Интересно, не знал про такое. Хотя, как по мне, выглядит это, мммм, немножно как костыли. :)
Я лично, напротив, не вижу проблемы в структурной типизации. Но может кому-то будет полезно узнать, что не обязательно страдать со структурной типизацией, когда она тебе поперёк горла.
Спасибо за статью, я вот как-то упустил появление f-string. Хотя хотелось бы увидеть более полное раскрытие темы — для меня осталось непонятным, почему f-string такие быстрые.
Если посмотреть примеры выше, то можно увидеть, что в случае с MobX я не использовал pure component и это не ошибка. Вам просто не надо использовать никакую оптимизацию в этом случае, потому что ваш компонент будет перерендериваться только тогда, когда данные, которые вы в нем используете поменяются.
В Redux совершенно аналогично — компонент, обёрнутый в connect(), будет перерендериваться только при изменении данных в store, на которые он подписан (или при изменении «внешних» props).
Иными словами, connect() реализует внутри себя shouldComponentUpdate(), который выполняет проверку props'ов на shallow equality, так что использование PureComponent для обёрнутого в connect() компонента абсолютно бессмысленно (и даже вредно).
С одной стороны согласен, с другой – настроить автоматическую пересылку писем с адресов уволившихся (или просто временно отсутствующих сотрудников) сотрудников не очень сложно, я много где такое встречаю.
с другой типобезопасность в моём понимании из-за структурной типизации не очень: ошибки, когда при копипасте забыл заменить user на Organization, не ловит, если нужны только id и name
Если использовать Flow с классами (вместо простых объектов), то такой проблемы не будет — Flow применяет к классам номинативную типизацию (или номинальную, не уверен, как лучше).
Не понял вопрос.
Если речь про JS-компонент без аннотаций типов — понятно, что неоткуда, нужны отдельные libdef'ы.
Но тут-то речь о существующей кодовой базе, в которой у компонентов уже есть аннотации типов на Flow.
Не совсем понял, как осуществляется взаимодействие сосуществующих TS и Flow?
Допустим, в TS-файле импортируется и используется компонент, написанный на JS+Flow, откуда TS узнаёт сигнатуру этого компонента?
Любой, кто смотрел первый сезон «Черного зеркала», помнит ту серию, в которой система социального кредита определяла привилегии и наказания, получаемые гражданами.
Всё чаще обращаю внимание, что для очень многих людей эпизоды Black Mirror, вышедшие до его покупки Netflix, просто не существуют, совсем.
Это когнитивное искажение тех, кто начинал смотреть с первого сезона и более всего ценит именно британские серии, или же действительно большая часть людей настолько безразлична к потребляемому им контенту, что напрочь игнорирует простейший факт, что они смотрят не первый сезон?
И синтаксис от Mozilla и Microsoft интересный. ждем.jpg
Я бы не особо надеялся. (:
Истории уже три с лишним года, а воз и ныне там. В в официальном списке proposal'ов в стандарт ES нет ни одного касающегося tail call, даже на stage 0.
Вы, видимо, изучили вопрос недостаточно подробно. :)
Дело в том, что в V8 (движок всех Chromium-based браузеров) tail call elimination давно реализована и… преднамеренно выключена его разработчиками. ¯\_(ツ)_/¯
Вот тут можно прочитать подробнее. Аргументация в целом очень похожа на таковую у Гвидо и у разработчиков Go (тут, увы, пруфов не будет), поэтому я упомянул об этом как о «принципиальной позиции разработчиков из Google».
1) Не увидел в книге по ссылке никаких дополнительных условий, кроме стандартного для tail call optimization требования, что рекурсивный вызов должен быть хвостовым (т. е. быть последней операцией в функции).
2) Рассуждения о преимуществах, которые даёт tail call optimization в JS, безусловно очень полезны и занимательны, но важно понимать, что в реальности они разбиваются о то, что в данный момент эта оптимизация поддерживается только в JSC (движок Safari). И, учитывая крайне принципиальную позицию разработчиков из Google, нет шансов, что это изменится в обозримом будущем.
Удалённый пользователь не может видеть удалённые файлы.
Помню, когда давным-давно читал Pro Git в русском переводе словосочетание «удалённая ветка» начиная с какого-то момента (когда осознал, что за ним может стоят одно из двух совершенно разных значений) вызывало подёргивание глаза одним своим видом. :)
Владельцы компании получают, хотя вряд ли прямо кэшем.
Для приватной компании это обычно какой-то ограниченный список людей (основатели, инвесторы и т. д.), для публичной — все, у кого есть акции компании.
Сотрудники (вне зависимости от того, рядовые или топ-менеджеры) получают деньги только если у них есть доля в компании (например, выдавали бонусы акциями). Просто так платить сотрудникам премии в честь продажи компании вряд ли кто-то станет. :)
Хотя нередко владельцы компании (заинтересованные в выгодной продаже компании), могут предложить CEO (генеральному директору) бонус за успешное оформление выгодной сделки. Но мне кажется, это касается только CEO, у прочих шансы на такой джекпот околонулевые.
Не очень ясно, почему type refinements неправильно отрабатывает конкретно здесь, но в целом проблемы такого рода не так редки, как хотелось бы.
FGJ, у TS с его type guards такие проблемы тоже есть (может, не этом конкретном случае, но на каком-то другом).
Я лично, напротив, не вижу проблемы в структурной типизации. Но может кому-то будет полезно узнать, что не обязательно страдать со структурной типизацией, когда она тебе поперёк горла.
Иными словами, connect() реализует внутри себя shouldComponentUpdate(), который выполняет проверку props'ов на shallow equality, так что использование PureComponent для обёрнутого в connect() компонента абсолютно бессмысленно (и даже вредно).
Подробнее можно прочитать в документации.
Если речь про JS-компонент без аннотаций типов — понятно, что неоткуда, нужны отдельные libdef'ы.
Но тут-то речь о существующей кодовой базе, в которой у компонентов уже есть аннотации типов на Flow.
Допустим, в TS-файле импортируется и используется компонент, написанный на JS+Flow, откуда TS узнаёт сигнатуру этого компонента?
К сожалению, основная проблема Operator Mono (для меня) — очень слабая кириллица, сильно контрастирующая по внешнему виду с латиницей.
Это когнитивное искажение тех, кто начинал смотреть с первого сезона и более всего ценит именно британские серии, или же действительно большая часть людей настолько безразлична к потребляемому им контенту, что напрочь игнорирует простейший факт, что они смотрят не первый сезон?
Истории уже три с лишним года, а воз и ныне там. В в официальном списке proposal'ов в стандарт ES нет ни одного касающегося tail call, даже на stage 0.
Дело в том, что в V8 (движок всех Chromium-based браузеров) tail call elimination давно реализована и… преднамеренно выключена его разработчиками. ¯\_(ツ)_/¯
Вот тут можно прочитать подробнее. Аргументация в целом очень похожа на таковую у Гвидо и у разработчиков Go (тут, увы, пруфов не будет), поэтому я упомянул об этом как о «принципиальной позиции разработчиков из Google».
2) Рассуждения о преимуществах, которые даёт tail call optimization в JS, безусловно очень полезны и занимательны, но важно понимать, что в реальности они разбиваются о то, что в данный момент эта оптимизация поддерживается только в JSC (движок Safari). И, учитывая крайне принципиальную позицию разработчиков из Google, нет шансов, что это изменится в обозримом будущем.
Для приватной компании это обычно какой-то ограниченный список людей (основатели, инвесторы и т. д.), для публичной — все, у кого есть акции компании.
Сотрудники (вне зависимости от того, рядовые или топ-менеджеры) получают деньги только если у них есть доля в компании (например, выдавали бонусы акциями). Просто так платить сотрудникам премии в честь продажи компании вряд ли кто-то станет. :)
Хотя нередко владельцы компании (заинтересованные в выгодной продаже компании), могут предложить CEO (генеральному директору) бонус за успешное оформление выгодной сделки. Но мне кажется, это касается только CEO, у прочих шансы на такой джекпот околонулевые.