Здесь происходит ошибка, потому что TypeScript не может знать, какой именно тип будет у formatter в runtime. Это не ts не умный, это в принципе невозможно в compile time.
Цель комментария была в том, чтобы объяснить, как правильно "готовить ts". Имелось ввиду, что для ts это невозможно. Ts не может знать, какой именно тип у formatter потому как не знает, какой именно тип будет у input. В наборе formatters нет такой функции, которая сможет принять input c данным объединением string | number | union. Другими словами, значение обязано быть, но функция сможет принять только самый узкий тип, в данном случае, never. С точки зрения ts вызов никогда не произойдет, поэтому мы видим у formatter тип (input: never) => string. Использование as, когда "единственное, что работает" - плохая практика, может привести к искажению типов, потому как в ts as - это просто допущение, а не реальный type-casting. Некоторые так и работают, руководствуясь принципом "чтобы ts не ругался". Если же отказаться от as (и any), то как решать такие задачки? С помощью type guard, описанных в приведенной статье из документации.
В общем, если принять мысль, что задача кожаного мешка сделать так, чтобы ts помогал, то пусть хоть как-то, но сам выводит типы. При условии, что type guards будут корректными, это гарантирует вам и корректность типов.
Есть вариант и с as. Нужно описать полный интерфейс у format, т.е. задать тип возвращаемого значения, а в теле функции делайте что хотите.
{} as string - синтетический пример, чтобы показать "оторванность" ts от рантайма, в отличие от статически типизированных языков. Хотите реальный пример? Вы описали интерфейс api response и на основе этого интерфейса далее выводите типы. А вам вдруг пришел response немного с другим интерфейсом. Скажем, бэкенд-тима решила, что некоторое поле будет с типом null, а не undefined, а вам не сказали (ничеси, неужели такое бывает?..). Статически типизированный язык заставит проверить типы или закастить. В ts этот фокус пройдет, но далее по коду может свалиться.
А авторский input as never (как и мой formatter as any) - это обход ложноотрицательного результата тайп-чекера в корректном коде.
Input as never... As never... Бессмыслица какая-то...
Здесь происходит ошибка, потому что TypeScript не может знать, какой именно тип будет у formatter в runtime. Это не ts не умный, это в принципе невозможно в compile time. В примере @Akuma явно делается проверка в switch (), поэтому происходит narrowing, и ts может гарантировать тип. Вы же просто "заткнули" ts, используя 'as never'. Вообще, если вы используете as, вы утверждаете, что здесь будет именно этот тип, даже если это в runtime не так. Попробуйте выполнить format({} as string) и ts ругаться не будет, а вот в runtime выскочит ошибка, в частности, formatter is not a function.
Просто есть "решатели" проблем, а есть "обсуждатели". Первые пытаются вникнуть в проблему, определить требования и найти или предложить решение. А вторые, может быть, не прочь делать то же самое, но как-будто и не пытаются. Просто производят много движений своим ртом. Авось, "в споре и родится истина". Да, объяснение не претендует на конструктивность. Но часто складывается именно такое впечатление. И никакие "эффективные" приемы таким не помогут.
По поводу разметки во Flutter:
1. Вопрос привычки. Со временем приспосабливаешься.
2. Нужно стараться сохранять виджеты небольшими.
Но:
3. Для разметки HTML или JSX, конечно, поприятней будут, т.к. XML-подобная разметка зрительно выделяется лучше.
О софте от Onyx: открываю на note 2 учебник по программированию в формате epub — а вместо разметки кода просто текст. Пришлось конвертировать в pdf, чтобы читать в стандартном приложении. Либо необходимо поискать стороннее приложение, которое выводит epub с поддержкой css.
Жизнь на Земле жила и развивалась при естественном фоне космических излучений. И плавно приспосабливалась. Люди изменили условия за короткий промежуток времени. И почему это будет иметь положительное влияние, если равновесие нарушено столь быстро?
Это такая ирония, что он помощника назвал Jarvis. Прям Тони Старк нашей реальности: и ИИ запрограммирует, и мини-коллайдер уровнем выровняет. Я шапочку из фольги не надеваю. Но уж больно это на пиар-компанию похоже.
«Влажные мечты» компаний. Все пытаются поднять хайп. А простые обыватели только смотрят на зарплаты.
Ну не будут все поголовно программировать! Работа для людей технического склада ума. Плюс сопряжена с рядом недостатков, как то: малоподвижный образ жизни, усталость глаз, умственное и нервное напряжение. Я не говорю, что это особенности только этой профессии. Но не каждый на это пойдет.
Да и сама работа должна нравиться. Как будто мало профессий умственного труда.
Как обычно вопрос состоит не в том, что лучше, а в том, что целесообразнее.
Всегда найдутся как плюсы, так и минусы. В случае с хранением логики в БЖ мы можем получить, например, большую производительность. Но тогда мы привязываемся к данной конкретной БД.
А за статью спасибо! Именно такого рода статьи должны быть на хабре.
И тип возвращаемого значения у format будет также
any
. Тогда ужеили указать тип возвращаемого значения у format явно
string
Цель комментария была в том, чтобы объяснить, как правильно "готовить ts". Имелось ввиду, что для ts это невозможно. Ts не может знать, какой именно тип у
formatter
потому как не знает, какой именно тип будет уinput
. В наборе formatters нет такой функции, которая сможет принятьinput
c данным объединениемstring | number | union
. Другими словами, значение обязано быть, но функция сможет принять только самый узкий тип, в данном случае,never
. С точки зрения ts вызов никогда не произойдет, поэтому мы видим у formatter тип(input: never) => string
. Использование as, когда "единственное, что работает" - плохая практика, может привести к искажению типов, потому как в tsas
- это просто допущение, а не реальный type-casting. Некоторые так и работают, руководствуясь принципом "чтобы ts не ругался". Если же отказаться отas
(иany
), то как решать такие задачки? С помощью type guard, описанных в приведенной статье из документации.В общем, если принять мысль, что задача кожаного мешка сделать так, чтобы ts помогал, то пусть хоть как-то, но сам выводит типы. При условии, что type guards будут корректными, это гарантирует вам и корректность типов.
Есть вариант и с
as.
Нужно описать полный интерфейс уformat,
т.е. задать тип возвращаемого значения, а в теле функции делайте что хотите.{} as string
- синтетический пример, чтобы показать "оторванность" ts от рантайма, в отличие от статически типизированных языков. Хотите реальный пример? Вы описали интерфейс api response и на основе этого интерфейса далее выводите типы. А вам вдруг пришел response немного с другим интерфейсом. Скажем, бэкенд-тима решила, что некоторое поле будет с типом null, а не undefined, а вам не сказали (ничеси, неужели такое бывает?..). Статически типизированный язык заставит проверить типы или закастить. В ts этот фокус пройдет, но далее по коду может свалиться.Input as never... As never... Бессмыслица какая-то...
Здесь происходит ошибка, потому что TypeScript не может знать, какой именно тип будет у
formatter
в runtime. Это не ts не умный, это в принципе невозможно в compile time. В примере @Akuma явно делается проверка в switch (), поэтому происходит narrowing, и ts может гарантировать тип. Вы же просто "заткнули" ts, используя 'as never'. Вообще, если вы используетеas
, вы утверждаете, что здесь будет именно этот тип, даже если это в runtime не так. Попробуйте выполнитьformat({} as string)
и ts ругаться не будет, а вот в runtime выскочит ошибка, в частности,formatter is not a function
.Просто есть "решатели" проблем, а есть "обсуждатели". Первые пытаются вникнуть в проблему, определить требования и найти или предложить решение. А вторые, может быть, не прочь делать то же самое, но как-будто и не пытаются. Просто производят много движений своим ртом. Авось, "в споре и родится истина". Да, объяснение не претендует на конструктивность. Но часто складывается именно такое впечатление. И никакие "эффективные" приемы таким не помогут.
Вывод типов - это из функционального программирования?
А есть ли разница с aot-snapshot?
1. Вопрос привычки. Со временем приспосабливаешься.
2. Нужно стараться сохранять виджеты небольшими.
Но:
3. Для разметки HTML или JSX, конечно, поприятней будут, т.к. XML-подобная разметка зрительно выделяется лучше.
Ну не будут все поголовно программировать! Работа для людей технического склада ума. Плюс сопряжена с рядом недостатков, как то: малоподвижный образ жизни, усталость глаз, умственное и нервное напряжение. Я не говорю, что это особенности только этой профессии. Но не каждый на это пойдет.
Да и сама работа должна нравиться. Как будто мало профессий умственного труда.
Всегда найдутся как плюсы, так и минусы. В случае с хранением логики в БЖ мы можем получить, например, большую производительность. Но тогда мы привязываемся к данной конкретной БД.
А за статью спасибо! Именно такого рода статьи должны быть на хабре.
… Нееет! © Борат