23.05.2023, 15:07
|
|
Тлен
|
|
Регистрация: 02.01.2010
Сообщений: 6,590
|
|
ksa, про порог вхождения - очень спорно. Сейчас собеседую чуваков, большинство сразу с ts начинали и без ts теряются.)
__________________
29375, 35
|
|
24.05.2023, 10:45
|
|
CacheVar
|
|
Регистрация: 19.08.2010
Сообщений: 14,231
|
|
Aetae, тут уже мне не понятно...
Одно дело когда нужно что-то писать (TS) и писать что-то правильно, а не абы что.
И когда вообще ничего не писать.
Второе однозначно проще.
Или к тебе приходят абсолютные эксперты по TS, без которого они уже ничего не могут сделать?
Просто ко мне приходят те, кто и JS-то может совсем не знать... А уж TS и подавно...
|
|
24.05.2023, 18:45
|
|
Тлен
|
|
Регистрация: 02.01.2010
Сообщений: 6,590
|
|
ksa, фишка в том что ts более строг, меньше свободы - проще в голову уложить. Само собой они не шарят за крутые фичи тюринг-полного ts.
Даёшь им банальный пример, типа:
class Some {
constructor(text) {
this.text = text;
}
//...
}
Они такие "Ачё всмысле, что это за this.text, отуда он взялся и что делает?...".
Всё потому что привкли, что рандомную хрень в класс писать низя, должно быть чётко:
class Some {
public text?: string;
constructor(text: string) {
this.text = text;
}
//...
}
=)
__________________
29375, 35
|
|
25.05.2023, 09:30
|
|
CacheVar
|
|
Регистрация: 19.08.2010
Сообщений: 14,231
|
|
Сообщение от Aetae
|
фишка в том что ts более строг, меньше свободы - проще в голову уложить
|
Мне приходится "подтягивать" новичков до приемлемого уровня программирования на JS, а это месяц-два (программировать на чем-то уже умеет)...
Если еще и TS-у учить до приемлемого уровня - еще время уйдет. Текста писать больше придется... Отсюда упадет скорость "выдачи" программного продукта... А его требуют достаточно много, при небольшом коллективе программистов.
Т.е. мы так не созрели для "поднятия планки" в разработке.
Там же ведь еще и тестирование "в спину дышит"! А на него еще такой же коллектив нужен, а то и покруче...
|
|
25.05.2023, 13:03
|
|
Профессор
|
|
Регистрация: 25.10.2016
Сообщений: 1,012
|
|
Субъективно: когда пишешь на ts, ощущение будто катишься по рельсам, но эти рельсы надо прокладывать (определять типы). А js - как раздолбанная проселочная дорога, и постоянно непонятно, что за объекты у тебя на руках и как с ними работать.
Прикол в том, что несмотря на дополнительный код, в продвинутой IDE (вебшторм или вс-код) это не проблема, потому что автокомплит позволяет очень быстро писать типы, кроме совсем хитрых кейсов, где надо прям подумать, и намного лучше работает при описании логики.
Автокомплит js там тоже неплох, но только если мы напрямую используем какие-то объекты, созданные прямо здесь же, или заимпортированные. Ну или классы. Любая разновидность инъекции (даже просто параметры функций) разваливает автокомплит в хлам.
Так же сила ts проявляется при рефакторинге, или просто каких-то изменениях. Когда поменяешь что-то там и сям, контроль типов очень помогает найти забытые куски кода.
В общем, плюсов много, использовать рекомендую.
|
|
25.05.2023, 15:21
|
|
Профессор
|
|
Регистрация: 14.11.2014
Сообщений: 186
|
|
Сообщение от Alexandroppolus
|
js - как раздолбанная проселочная дорога
|
Не слишком ли резковатое высказывание?)) XD
По аналитике можно сделать вывод, что TS — это исключительно статическая типизация.
У меня есть сильное чувство, что её просто скоро завезут в JS. Ибо он всё более и более низкоуровневым становится. И причём можно будет как указывать тип, так и нет (наподобие как в PHP).
По мне так даже лучше, когда у тебя есть выбор. Сначала просто накидать код, чтоб быстрее реализовать результат. А потом можно и типы проработать. В общем, кто как хочет и кому как удобнее.
А где вообще можно отслеживать предлагаемые нововведения в JS? Голосовать там или даже предлагать?)
|
|
25.05.2023, 17:54
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,753
|
|
Сообщение от Nexus
|
Особенно это помогает при работе с внешними данными: отпадает нужда каждый раз смотреть в консоли набор каких данных вернул сервер.
|
Мне в ответ сервер (сторонний api) возвращает такой json
{
"status": "ok",
"message-type": "work",
"message-version": "1.0.0",
"message": {
"indexed": {
"date-parts": [[2022, 12, 26]],
"date-time": "2022-12-26T14:49:48Z",
"timestamp": 1672066188725
},
"reference-count": 5,
"publisher": "Keldysh Institute of Applied Mathematics",
"issue": "82",
"content-domain": { "domain": [], "crossmark-restriction": false },
"short-container-title": ["KIAM Prepr."],
"published-print": { "date-parts": [[2017]] },
"DOI": "10.20948/prepr-2017-82",
"type": "journal-article",
"created": {
"date-parts": [[2017, 9, 15]],
"date-time": "2017-09-15T10:21:58Z",
"timestamp": 1505470918000
},
"page": "1-14",
"source": "Crossref",
"is-referenced-by-count": 4,
"title": ["Updated revision date for reference to alive publication"],
"prefix": "10.20948",
"author": [
{
"ORCID": "http://orcid.org/0000-0002-7044-8287",
"authenticated-orcid": false,
"given": "Mikhail Mikhailovich",
"family": "Gorbunov-Possadov",
"sequence": "first",
"affiliation": [
{ "name": "Keldysh Institute of Applied Mathematics" }
]
},
{
"ORCID": "http://orcid.org/0000-0001-7372-3574",
"authenticated-orcid": false,
"given": "Rimma Yuryevna",
"family": "Skornyakova",
"sequence": "additional",
"affiliation": [
{ "name": "Keldysh Institute of Applied Mathematics" }
]
}
],
"member": "8521",
"published-online": { "date-parts": [[2017]] },
"reference": [
{
"key": "1",
"unstructured": "\u0413\u043e\u0440\u0431\u0443\u043d\u043e\u0432-\u041f\u043e\u0441\u0430\u0434\u043e\u0432 \u041c.\u041c. \u0416\u0438\u0432\u0430\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u044f // \u041e\u0442\u043a\u0440\u044b\u0442\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u2014 2011, \u2116 4. \u2014 \u0421. 48\u201349. \u2014 URL: http://keldysh.ru/gorbunov/live.htm"
},
{
"key": "2",
"doi-asserted-by": "publisher",
"unstructured": "\u0413\u043e\u0440\u0431\u0443\u043d\u043e\u0432-\u041f\u043e\u0441\u0430\u0434\u043e\u0432 \u041c.\u041c. \u0418\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u043a\u0430\u043a \u043e\u0431\u044f\u0437\u0430\u043d\u043d\u043e\u0441\u0442\u044c \u0443\u0447\u0435\u043d\u043e\u0433\u043e \u2014 [\u0431.\u2009\u043c.]: \u0418\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u044f, 2017. \u2014 64 \u0441. \u2014 doi:10.20948/ridero-2017-gorbunov \u2014 ISBN 978-5-4483-7792-1",
"DOI": "10.20948/ridero-2017-gorbunov"
},
{
"key": "3",
"unstructured": "\u0416\u0438\u0432\u0430\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u044f: \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 \u2014 URL: http://alive.keldysh.ru"
},
{
"key": "4",
"unstructured": "Dublin Core Metadata Initiative. \u2014 URL: http://dublincore.org/"
},
{
"key": "5",
"unstructured": "\u0410\u0432\u0442\u043e\u0440\u0443 \u043f\u0440\u0435\u043f\u0440\u0438\u043d\u0442\u0430 \u0418\u041f\u041c \u0438\u043c.\u041c.\u0412.\u041a\u0435\u043b\u0434\u044b\u0448\u0430 \u2014 URL: http://keldysh.ru/preprints/"
}
],
"container-title": ["Keldysh Institute Preprints"],
"original-title": [
"\u041e\u0431\u043d\u043e\u0432\u043b\u044f\u0435\u043c\u0430\u044f \u0434\u0430\u0442\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0439 \u0440\u0435\u0434\u0430\u043a\u0446\u0438\u0438 \u0432 \u0441\u0441\u044b\u043b\u043a\u0435 \u043d\u0430 \u0436\u0438\u0432\u0443\u044e \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u044e"
],
"deposited": {
"date-parts": [[2020, 1, 16]],
"date-time": "2020-01-16T09:06:58Z",
"timestamp": 1579165618000
},
"score": 1,
"resource": {
"primary": {
"URL": "http://keldysh.ru/papers/2017/prep2017_82.pdf"
}
},
"subtitle": [],
"short-title": [],
"issued": { "date-parts": [[2017]] },
"references-count": 5,
"journal-issue": {
"issue": "82",
"published-online": { "date-parts": [[2017]] },
"published-print": { "date-parts": [[2017]] }
},
"URL": "http://dx.doi.org/10.20948/prepr-2017-82",
"relation": {},
"ISSN": ["2071-2898", "2071-2901"],
"issn-type": [
{ "value": "2071-2898", "type": "print" },
{ "value": "2071-2901", "type": "electronic" }
],
"subject": ["General Medicine"],
"published": { "date-parts": [[2017]] }
}
}
В котором, меня интересует лишь пара полей.
Сколько времени уйдет на точное описание на ts такого объекта
(И знать бы еще, что другие поля означают)
И как описание объекта поможет, если вдруг в api что то поменяют? Например, добавят какие то поля?
Последний раз редактировалось voraa, 25.05.2023 в 18:00.
|
|
25.05.2023, 18:13
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,753
|
|
Сообщение от webgraph
|
У меня есть сильное чувство, что её просто скоро завезут в JS.
|
Ну есть такие предложения. Но описания типов только для пишущего и читающего код. Сам движок никакой проверки производить не будет. Он будет считать такие описания комментариями. Для IDE это будет помощь. Но в принципе такое уже есть - JSDOC. VSCode вполне успешно с ним работает. Почти, как в ts (некоторые возможности не реализованы) - проверяет типы объектов, переменных, функций... Но более многословен, чем ts
Одно из преимуществ - отсутствие этапа компиляции. В небольших проектах, по мне, он нафиг не нужен.
Код передается браузеру как есть. Может быть спокойно минификирован.
Например, кусок кода с JSDOC
/**
* @typedef BiblioElemNum
* @type {{
* [id:string]:{
* elem:HTMLElement,
* num:number,
* cites:HTMLAnchorElement[],
* }
* }}
*/
/**
* @type {?BiblioElemNum}
*/
let biblioids = null;
/**
* @param {HTMLElement} elem
*/
const insertBiblioBut = (elem) => {
elem.style.position = 'relative';
const biblbut = /** @type {DocumentFragment} */ (bibliobut.cloneNode(true));
$data(
/**@type {HTMLElement}*/ ($di(biblbut, 'p-biblio-but')),
'p-biblio-id',
elem.id
);
elem.append(biblbut);
};
/**
* @param {HTMLElement} cont - контейнер с элементов библиографии
* @returns {BiblioElemNum}
*/
const findBiblios = (cont) => {
$data(cont, 'p-biblio-cont', '');
return /**@type {HTMLElement[]} */ (Array.from(cont.children)).reduce(
(a, e, i) => {
if (e.id)
a[e.id] = {
elem: e,
num: i + 1,
cites: [...getCitesById(e.id)],
};
if (a[e.id].cites.length) insertBiblioBut(e);
else
console.warn(
`Нет отсылок на элемент библиографии ${a[e.id].num} с id="${
e.id
}"`
);
return a;
},
/**@type BiblioElemNum*/ ({})
);
};
/**
* @param {string} id - id элемента библиографии
* @returns {NodeListOf<HTMLAnchorElement>}
*/
const getCitesById = (id) => {
return /**@type {NodeListOf<HTMLAnchorElement>} */ (
$a(`a.${crefbiblio}[href="#${id}"]`)
);
};
Последний раз редактировалось voraa, 25.05.2023 в 18:21.
|
|
25.05.2023, 18:50
|
|
Тлен
|
|
Регистрация: 02.01.2010
Сообщений: 6,590
|
|
Сообщение от voraa
|
Сколько времени уйдет на точное описание на ts такого объекта
|
Примерно пара секунд - закинуть сюда https://app.quicktype.io/ и скопировать результат.)
Но на практике в более-менее приличном проекте интерфейсы сервера генерируются на лету и из swagger модели автоматически соответствующими тулзами.
По поводу jsdoc - нахрен не нужен в современном вебе. Гораздо более неудобная херня, чем TS при том же смысле. Сейчас без сборки на фронте практические ничего не делается всё равно, чтоб имело смысл с ним возиться.
Сообщение от webgraph
|
И причём можно будет как указывать тип, так и нет
|
Так TS в большинстве случаев выводит типы за тебя. Указывать надо только там, где заведомо какая-то непонятная из кода хуйня.
__________________
29375, 35
Последний раз редактировалось Aetae, 25.05.2023 в 19:03.
|
|
25.05.2023, 19:14
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,753
|
|
Ругается на
"\u0413\u043e\u0440\u0431\u0443\...."
Сообщение от Aetae
|
Но на практике в более-менее приличном проекте интерфейсы сервера генерируются на лету и из swagger модели автоматически соответствующими тулзами.
|
Это не мой сервер, это совершенно сторонний апи
Последний раз редактировалось voraa, 25.05.2023 в 19:16.
|
|
|
|