Комментарии 67
А голосовать не могу по причине неполноценного аккаунта…
Тем, что информация про то, можете ли вы голосовать, или нет — никак не относится к теме статьи, а потому излишня. Тем более выглядит, как выпрашивание кармы. Представьте, что тут будет, если каждый, кто не может голосовать напишет, что он не может голосовать.
Мафия голосовантов, из которых сыпется песок (да, я помню 2005-е), прочно занимает свои позиции и не пускает новичков
Я понимаю, что ныть и клянчить карму легче, чем писать объемные технические статьи, но будьте честными хотя-бы с собой.
В w3schools считают (очевидно, ошибочно) ECMAScript официальным названием JavaScript'а:
JavaScript was invented by Brendan Eich in 1995, and became an ECMA standard in 1997.Всё же диалект и официальное название — не одно и то же.
ECMA-262 is the official name of the standard. ECMAScript is the official name of the language.
Хотелось бы узнать, какие ещё диалекты есть у ECMAScript. Например, является ли ActionScript его диалектом, и если нет, то почему.
ECMAScript — это спецификация, на которую он забил ))
bakkot.github.io/test262-web-runner
интересно, расскажите поподробнее, почему так
Есть спецификация ECMAScript, и есть множество движков, реализующих то или иное пересекающееся (обычно) со этой спецификацией множество диалектов JavaScript. Вроде ни один движок ещё не реализует ECMAScript полностью с одной стороны, а с другой — все имеют возможности или особенности, непредусмотренные спецификацией.
В наши дни я бы не стал называть English языком. Сейчас это, скорее, семейство языков, как когда то было популярно семейство языков LATIN.
Если это так, то подскажите, как Брендан Эйх смог его сплагиатить в конце 1995 года, когда ECMAScript 1.0 появился в 1997? Ему рассказал Т-800 или Эммет Браун?
А я думал, что когда дело дошло до стандартизации, то из-за опасения копирайта на Java часть в названии, её заменили на всякий случай на ECMA. После чего «JavaScript» стал народным названием языка, а ECMAScript официальным.
Иначе временной парадоксс и вообще не понятно кто на этом ECMAScript пишет.
Не претендую на истинность, версий слишком много
Спасибо. Оттуда и почерпнул информацию. Хорошо написано, с удовольствием прочитал второй раз.
О себе могу сказать, что пишу на ES2015, всё реже на ES5.
А если я скажу, что «пишу на JavaScript» — не сильно конкретизирует и может означать как то, что было на старте тысячелетия с падающими снежинками (при этом нужно обязательно уточнить браузер), так и классы, промисы, импорты и прочие плюшки современности.
В заключении к первой статье из цикла об истории JS, пишут такое:
На сегодняшний день JavaScript это всего лишь коммерческое название ECMAScript.
ИМХО JavaScript — не стандарт, а поле боя для браузерных войн толкающих свои стандарты
Множество субъективных и объективных факторов… В частности командная разработка не дадут так просто изменить стек технологий.
Кстати es6 / es2015 это разве не одно и то же?
ES6 — всё таки стандарт ДжаваСкрипта, а подмножества вроде CoffeScript неплохое поле для обкатки новых идей, самые (недеюсь) годные из которых перекачёвывают в ESNext, а сами подмножества медленно отмирают. Андерс Хейлсберг конечно уважаемый человек, но и его детище может уступить дорогу новому стандарту.
За 12 лет привык к динамической типизации, статическую типизацию мне заменяют prop-types и регистровая типизация (смешиваю всякие снейк_кебаб-КамельКейсы для разных типов, в т.ч. для имён файлов)
В данный момент не вижу причин усиленно разбираться с TS, но учитывая встроенную поддержку IDE ваша рекомендация прибавила желания попробовать.
ЗЫ что-то мне подсказывает, что избавившись от бабеля нельзя просто так взять и избавиться от тяжести той работы которую он выполняет. Я так понимаю у вас уже серьёзный проект с большим количеством кода, сколько времени занимает промежуток от ctrl+s до завершения компиляции?
мне заменяют prop-types
Они уже deprecated — рекомендуют переходить на ts / flow. flow — это просто типы, т.е все-равно нужен внешний инструмент для их обрезания — тот же бабель с плагином.
В данный момент не вижу причин усиленно разбираться с TS
Любой js — это валидный ts (с отключенными проверками). Вот от этого знания и следует плясать дальше, постепенно подкручивая гайки на проверки типов и т.п.
сколько времени занимает промежуток от ctrl+s до завершения компиляции?
Я не фронтендщик, для бекенда достаточно использовать штатный механизм ts для транспиляции: tsc -w. В паре последних версий был прикручен инкрементальный режим + оптимизирована скорость. Вообще, транспайлинг занимает максимум секунду, возможно 3-4 первый раз. Но это сильно зависит от сложности кода и его количества. Для фронтенда, если нужна минификация + бандлинг — могу посоветовать fuse-box.org — заменяет вебпак, любит ts из коробки, летает как самолет.
Они уже deprecated
Ничего они не deprecated
Просто переехали в отдельный пакет из Реакта:
Ничего они не deprecated
Ну я воспользовался формулировкой о «New Deprecation Warnings» с официального сайта: reactjs.org/blog/2017/04/07/react-v15.5.0.html
Ну и в консоли писалось:
React.PropTypes is deprecated since React 15.5.0, use the npm module prop-types instead
Да, отдельный модуль, но нужно ли оно, если валидация происходит только после запуска, а в случае с ts / flow — прямо при написании кода?
Да, отдельный модуль, но нужно ли оно, если валидация происходит только после запуска, а в случае с ts / flow — прямо при написании кода?
Вот именно, что возбраняется React.PropTypes и вместо него рекомендуют использовать отдельный пакет prop-types. Это как бы намекает на выход парадигмы за пределы экосистемы ReactJS, что косвенно подтверждает эффективность.
Ты — бэкендщик, я — фронтендщик, нам Дург друга не понять.
Не проблема, что валидация происходит только после запуска. Запуск и перезапуск для меня естественное состояние, а учитывая hotReload ещё и автоматическое. Консоль браузера почти всегда открыта, а даже если в мастер ветку попадёт неправильно объявленный тип, мне об этом сообщат на стадии интеграции.
Возможно твоя любовь к статической типизации объясняется подходом к разработке при котором приложение может писаться часами, а после запускается и работает.
Когда корректность работы каждого кусочка программы проверяется во время написания итеративными правками, то это возможно не так важно.
То, что я сам себе тестер съедает конечно порядочно времени, но не уверен, что статическая типизация мне его сэкономит.
Расскажи как часто ты запускаешь код который пишешь? Раз в минуту, пять, час, день…?
ЗЫ я не призываю тебя съехать с TS, скорее изучаю дружественную пати
По поводу среды разработки и ошибок: в той же vscode все гораздо приятнее — там валидация делается через фоновый language server в реалтайме и ты ошибки видишь сразу с подчеркиваниями и иногда даже с автоматическими хотфиксами в стиле resharper-а. Про ошибки в рантайме — это плохо, если для нужного функционала нужно ползти долго через несколько промежуточных этапов, ну или пытаться повторить кейс через автотесты со сложно добываемым состоянием окружения.
А если метод вызывается не на прямую, а погружен глубоко в недры декораторов, или ещё чего, что его пропускает сквозь себя, это тоже будет работать?
С PropTypes такая пичаль, что нельзя сделать
static propTypes = {...modificators, ...themes}
и сохранить подсказки при заполнении пропсов. А приём таки необходимый в некоторых ситуациях, иначе приходится дублировать списки, чтобы оставить PropTypes в примитивном виде. Вся надежда на разработчиков IDE
Наверное стоит объяснить зачем мне это. Проще всего будет на компоненте иконок.
Есть компонент <Icon />, его можно использовать так <Icon search x2 /> и это отрендерит иконку с лупой двойного размера. В таком формате можно получать подсказки к названию иконок, но после разделение пропсов на имена иконок и модификаторы, для последующего использования ключей этих списков внутри класса, часть профита, в виде автодополнения, теряется. Разработчик шторма услышь мои стенанья
А если метод вызывается не на прямую, а погружен глубоко в недры декораторов, или ещё чего, что его пропускает сквозь себя, это тоже будет работать?
С ts нужно или руками кастовать к нужному типу или к any, чтобы отключить проверку типов. Т.е все-равно какой-то тип нужен.
С PropTypes такая пичаль, что нельзя сделать
Тут скорее всего придется завести интерфейс с указанием доступных полей и использовать его при создании инстанса нового типа — IDE потом будет использовать этот интерфейс для подсказок в интеллисенсе.
<Icon search x2 />
В ts это можно сделать как-то так:
export interface IProps {
search?: boolean;
x2?: boolean;
}
export class Icon extends React.Component<IProps, {}> {
public render() {
// И вот тут IDE (например, vscode) будет показывать полноценный intellisense с возможными свойствами и их типами.
const search = this.props.search;
const x2 = this.props.x2;
...
}
}
Аналогично, полноценные подсказки по возможным свойствам и их типам будут появляться в месте подстановки этой иконки в родительском компоненте.
Есть деструкторы же, так куда лаконичнее:
const { props: { search, x2 }} = thisчем:
const search = this.props.search;
const x2 = this.props.x2;Так и так мою задачу не решают. Можно наследовать два и более интерфейсов? Свойства интерфейса можно перебирать через .map например?
Есть деструкторы же
Задачи написать как можно короче не было, нужно было показать место где IDE будет понимать / показывать свойства и их типы.
Можно наследовать два и более интерфейсов?
Можно реализовывать несколько интерфейсов.
Свойства интерфейса можно перебирать через .map например
Интерфейсы — это сущности времени транспиляции / статической проверки типов (по сути — набор требований, которые должны выполняться для передаваемых инстансов). На выходе получается чистый js безо всяких фишек ts, о каком переборе свойств через .map идет речь?
Хочется иметь возможность все пропсы с этого уровня вложенности вычистить, чтобы передать тегу вниз. Или найти название темы в пропсах:
getPropsWithoutModifiers() {
return _.omitBy(this.props, propInModifiersIntarface)
}
getPropsWithoutThemes() {
return _.find(this.props, nameInThemeInterface) || 'default'
}Читаю это, норм? Там нашёл, что интерфейсы наследуются так-же как и классы, это здорово. Совсем забыл обо всей этой кухне с тех пор как перестал на PHP писать
интерфейсы наследуются так-же как и классы, это здорово.
Только не наследуются, а реализуются (implements) — т.е на тип накладываются ограничения-требования и чтобы инстанс объекта мог работать через интерфейс-абстракцию — он должен реализовывать все перечисленные ограничения-требования. Это все проверяется только в IDE / транспайлере, никаких проверок в рантайме нет. Т.е мы максимально закручиваем гайки в момент написания кода и облегчаем рантайм на все уже ненужные проверки типов / значений. Разумеется, все данные, приезжающие снаружи в рантайме, нужно валидировать на совместимость, но дальше все должно работать достаточно стабильно.
В рантайме девелопера конечно остаются, что немного сказывается на производительности, но не критично.
И раз для данных прибывающих из вне такая пичалька, то все равно приходится использовать нечто вроде prop-types для данных приходящих по API (а у меня это большинство данных)?
const { props: { search, x2 }} = thisЛучше так:
const { search, x2 } = this.propsТак и так мою задачу не решают. Можно наследовать два и более интерфейсов? Свойства интерфейса можно перебирать через .map например?
Объясните задачу. Если я вас правильно понял, то самое простое:
type IPropsX2 = { x2: boolean };
type IPropsSearch = { search: boolean };
type IIconProps = IPropsX2 | IPropsSearch;
class Icon extends Component<IIconProps> {}
// или даже так:
class Icon extends Component<IPropsX2 | IPropsSearch> {
render () {
return this.props. // x2|search
}
}
Хотя это, скорее
IPropsX2 или IPropsSearch. Можно использовать type IIconProps = IPropsX2 | IPropsSearch;. Но для пропсов я предпочитаю вариант с интерфейсами:
interface IPropsX2 { x2?: boolean }
interface IPropsSearch { search?: boolean }
interface IIconProps implements IPropsX2, IPropsSearch {}
class Icon extends Component<IIconProps> {
render () {
return this.props. // x2|search
}
}
Мар (и другие Дженерик-функции) работают так, как того от них ожидаешь:
interface IFoo { foo: boolean }
interface IBar { bar: boolean }
class Item implements Foo, Bar { /* ... */ }
const items: Item[];
items.map(it => it.); // тут или it.foo или it.bar
IDE автодополнит, корректно расчитает возвращаемый тип и вся цепочка будет типизированной.
Ты — бэкендщик, я — фронтендщик, нам Дург друга не понять.
Я фронтендщик и считаю, что проп-тайпы должны умереть как кривой и ненужный костыль. Основная их проблема, помимо прочего — они работают очень ограничено. Шаг вправо, шаг влево — не работают. Пример — я хочу вынести колбек в метод:
interface IFoo {
id: number;
title: string;
}
inteface IFooListProps {
items: IFoo[];
}
class FooList extends Component<IFooListProps> {
render () {
return <ul>{this.props.items.map(this.renderItem)}</ul>;
}
renderItem(item: IFoo) {
return <li key={item.id}>{item.title}</li>;
}
}
Как PropTypes будут работать на этом примере? Как говно. Чем они и есть.
Как PropTypes будут работать на этом примере?
Не очень силён в TS, чтобы точно сказать как себя поведут здесь типы, вижу интерфейсы, а чего там дальше с ними происходит — искТри. Вот вы скажите у вас проптайпы начинают пахнуть или, что? Без TS туда можно свои функции с любыми проверками отправлять. Имхо гибко, не?
const { search, x2 } = this.propsВы же выносите метод в класс, используете его в соседнем методе. Мой деструктор без проблем позволит добавить в него методы компонента и стейт, а не вермешелить ниже в методе. А вы просто ими не пользуетесь и пишите this.props.items.map(…
На вашем примере это выглядело бы так:
lass FooList extends Component<IFooListProps> {
render () {
const { props: { items }, renderItem }
return <ul>{items.map(renderItem)}</ul>;
}
renderItem({id, title}: IFoo) {
return <li key={id}>{title}</li>;
}
}А по поводу моей задачи есть смысл её дальше формировать только если можно взять интерфейс и получить его ключи из метода компонента.
«TS интерфейс итерация» у Гугла ничего не дал
«TS интерфейс итерация» у Гугла ничего не дал
а если погуглить на английском: "typescript get interface keys", то найдется релевантный вопрос: https://stackoverflow.com/questions/37214961/is-it-possible-to-loop-through-all-objects-in-an-interface-to-get-key-and-value
Ну и от себя добавлю, что у вашей задачи (в глобальном смысле), может быть другое решение, в котором итерация по ключам не требуется
И вот кстати решение
Всем спасибо, было очень интересно узнать о TS, открыл для себя новую тему для чтения. Возможно когда нибудь удастся убедить остальных членов команды это попробовать.
Это не решение, это костыль.
По идее, что PropTypes, что типы из Typescript в продакшен режиме должны выпиливаться из кода совсем. Поэтому не стоит на них строить свою бизнес логику.
Правильным решением вашей проблемы может быть два варианта
- Вместо вливания нескольких свойств themes объявляем одно свойство theme и везде передаем только его.
- Использовать существующие библиотеки для темизации, вместо своего решения. Есть ThemeProvider в styled-components, есть независимая библиотека theming. Что характерно, в них обоих параметры темы передаются как раз-таки едиственным свойством theme.
Что характерно, в них обоих параметры темы передаются как раз-таки едиственным свойством theme.
Вот они не осилили и я тоже должен сдаться по вашему?
С одним параметром вообще никаких проблем, дело в фишке с автодополнением (и оно у меня кстати работает если не сепарировать пропсы по группам). Спред в пропсы ломает автодополнение.
Хотя я не пользовался этими инструментами и возможно гоню. Может там текстовое поле с названием темы тоже автодополняется? Попробовал через enum .oneOf([…]), нет эффекта.
Ещё раз скорректирую свою цель:
Получение максимально лаконичного решения с сохранением автокомплита в IDE
Я надеюсь в следующих версиях IDE появится поддержка расширения пропсов из соседних объектов (а когда их очень много, очень хочется хранить их в отдельном файле)
ЗЫ Я понимаю, что это похоже на хак архитектуры, но может я заразный и такие практики войдут в обиход?
Получение максимально лаконичного решения с сохранением автокомплита в IDE
IDE предлагает автокомплит на основе статического анализа, а вообще конструкция {...modifiers, ...themes} — динамическая, поэтому поддерживаться не будет в принципе.
Поэтому выбирайте: либо красивый код для вас, либо понятный для инструментов разработки
{...modifiers, ...themes} — динамическая, поэтому поддерживаться не будет в принципе.
Почему нет? Для C# это странный подход, но TS вполне справится:
const modifiers: Mods;
const themes: Themes;
const mixed: (Mods & Themes) = { ...modifiers, ...themes }Не самая прогрессивная «IDE»:
искТри
Что это за слово?
Без TS туда можно свои функции с любыми проверками отправлять. Имхо гибко, не?
Эти функции можно засунуть только в одно место… — на вход реакт-компонента. Не вижу ничего гибкого. Валидация должна быть на стороне модели, а не во вьюшке. Тем более вся валидация — это выплюнуть варн в консоль. И никак не обработать. И работает только на дев-стейджинге. Какой в ней смысл? Никакого!
Вы же выносите метод в класс, используете его в соседнем методе.
Блин, ну я же пример, который показывает говняность ПропТайпов приводил. При чем тут деструктуризация? ПропТайпы говняны что с ней, что без нее.
деструктор без проблем позволит добавить в него методы компонента
Это ошибочное решение. Метод если занесете метод в переменную — рано или поздно обязательно кто-то вызовет такой метод без контекста и заделает баг. Методы в переменную не заносятся, а используются только с `this`. А в целом я не вижу смысла деструктуировать ВСЕ просто потому-что можно
Переубеждать тебя не хочу. Не ходи в мои кейсы со своим говномётом. Ни к чему эта агрессия. ॐ
через const метод затрут
При чем тут const? Где я сказал слово «затрут»?
// первый пример:
const { method } = this;
return method();
// второй пример:
return this.method();Вы понимаете, что эти два примера работают по-разному и в первом возможны неприятные баги?
Понял о каком баге идёт речь, вижу его очень часто. Выявляется молниеносно в момент написания. Метод переписывается на свойство со стрелочной функцией и всё встаёт на свои места.
К деструктурированию всего пришёл постепенно. Сначала занимался этим по мере надобности, но потом выяснилась, что такая надобность регулярно возникает в будущем, и приходится снова и снова переписывать деструкторы в разных местах, как только метод становится сложнее.
ЗЫ ожидаю теперь комментария о том, что стрелочные функции — говно
Не вижу ничего гибкого. Валидация должна быть на стороне модели, а не во вьюшке. Тем более вся валидация — это выплюнуть варн в консоль. И никак не обработать. И работает только на дев-стейджинге. Какой в ней смысл? Никакого!
И тем не менее мы работаем командами. Я в той, что пишет UI, есть те кто его использует и работает с API, есть те кто пишет API. Вот между первой и второй командой эти проптайпы приносят пользу, к продакшену всё должно быть многократно протестировано.
Понял о каком баге идёт речь, вижу его очень часто. Выявляется молниеносно в момент написания
Вот только это из тех багов, которые: «та, я просто деструктуирую, чтобы красивенько было, зачем тестеров предупреждать, ничего плохого не случится, сто раз так делал»
ЗЫ ожидаю теперь комментария о том, что стрелочные функции — говно
Обратите внимание, я не называл ВСЁ говном, только ПропТайпы — ведь они совершенно бессмысленны и не нужны. А деструктуризация и стрелочные функции — хороши в меру.
И я уже объяснил где пригодяться propTypes. У нас разный рабочий поток. Моим компонентам передаются минимально необходимые параметры, внутренняя кухня не касается тех кто будет их использовать. А вот мне их читать и перечитывать предстоит скорее всего ещё не раз. В этом случае удобство чтения мной в приоритете.
Стрелочные функции отлично с этим справляются. Теперь скорее .bind(this) — костыль
Вы второй раз за меня додумываете. Где я говорил, что необходимо использовать bind? Я же сказал, что стрелочные фукнкции хороши в меру, а не что надо использовать bind.
А как вам вот вариант из вот этого ответа: https://ru.stackoverflow.com/a/709112/178779? Решение проблемы или жуткий костыль? А то я сам пока сомневаюсь...
И тем не менее мы работаем командами. Я в той, что пишет UI, есть те кто его использует и работает с API, есть те кто пишет API. Вот между первой и второй командой эти проптайпы приносят пользу, к продакшену всё должно быть многократно протестировано.
Значительно больше пользы принесла бы статическая типизация — вы бы могли организовать проверку не только по пути
UsingApi => UIApi => UsingApi => UI => UsingApi => ApiА еще не только между слоями, но и внутри слоев. Ни одно, ни второе проп-тайп не позволяет.
Видите, о чем я говорю? Из-за отвратительного инструмента вы покрываете от силы 20% проверками вместо 100%. Но из-за стокгольмского синдрома не способны заметить, что инструмент отвратительный и всеми силами его защищаете.
Текущий проект конечно и речи апрейдить нет, тут на React16 не могу протолкнуть обновление, не то, что смену стека. Так, что —
что имеем то и защищаем, пока живу с prop-types
Но поскольку JavaScript соответствует спецификации ECMAScript, JavaScript является примером реализации ECMAScript.
Получается, что ECMAScript основан на JavaScript, а JavaScript основан на ECMAScript.
Причинно-следственные связи у автора не совсем корректно работают.
расследование одной строкой:
«Был JavaScript, под него написали спецификацию ECMA. „
Это элементарно, Ватсон!
Никаких споров о курице и яйце.
Из спецификации ECMAScript вы узнаете, как создать скриптовый язык
Из спецификации ECMAScript мы узнаем как создавался JavaScript и может написать расширения или модифицированный JavaScript, например ActionScript.
Говоря о поддержке в браузерах, обычно упоминают о «совместимости с ECMAScript», а не о «совместимости с JavaScript», хотя JavaScript-движки детально анализируют и выполняют… JavaScript.
Нет. Люди в первую очередь говорят о «совместимости с JavaScript».
Откуда пошла моду усложнять все? Придумывать какие то свои правила, давать определения уже существующим методам и впаривать их всем?
Все эти плейсхолдеры, паттерны? Оно все было изобретено и продумано еще до рождения юнных стартаперов, которые это пропагандируют.
Ощущение что цель это просто напустить интригу и завуалировать деятельность программистов.
Нет. Люди в первую очередь говорят о «совместимости с JavaScript».
Говорить стоит о совместимости с версией JavaScript, которая выражается в номерах ECMAScript.
Сейчас большинство браузеров полностью совместимы с ECMAScript 3.1 5, частично с ES6 ES2015.
ES3 код должен работать корректно во всех браузерах с начала второго тысячелетия
Подробнее об этом рассказано в этом цикле статей → Как появился Mocha/LiveScript, позже переименованный в JavaScript.
Чем отличаются JavaScript и ECMAScript?