Как стать автором
Обновить
0
0
Алексей @AlexAkhremenko

Пользователь

Отправить сообщение

И тип возвращаемого значения у format будет также any. Тогда уже

const formatter = formatters[inputType] as (input: string | number | boolean) => string

или указать тип возвращаемого значения у format явно string

Здесь происходит ошибка, потому что 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 не ругался". Если же отказаться от asany), то как решать такие задачки? С помощью 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.

Просто есть "решатели" проблем, а есть "обсуждатели". Первые пытаются вникнуть в проблему, определить требования и найти или предложить решение. А вторые, может быть, не прочь делать то же самое, но как-будто и не пытаются. Просто производят много движений своим ртом. Авось, "в споре и родится истина". Да, объяснение не претендует на конструктивность. Но часто складывается именно такое впечатление. И никакие "эффективные" приемы таким не помогут.

Скорее, все упирается в скорость анимаций. Это пока и есть бутылочное горлышко.

возможности функционального  (например, вывод типов, сопоставление с образцом, замыкания)

Вывод типов - это из функционального программирования?

Можно ли лучше? В принципе да. Выполняем dart compile exe и получаем ускорение на 10% или 9.00 секунд.


А есть ли разница с aot-snapshot?
По поводу разметки во Flutter:
1. Вопрос привычки. Со временем приспосабливаешься.
2. Нужно стараться сохранять виджеты небольшими.
Но:
3. Для разметки HTML или JSX, конечно, поприятней будут, т.к. XML-подобная разметка зрительно выделяется лучше.
О софте от Onyx: открываю на note 2 учебник по программированию в формате epub — а вместо разметки кода просто текст. Пришлось конвертировать в pdf, чтобы читать в стандартном приложении. Либо необходимо поискать стороннее приложение, которое выводит epub с поддержкой css.
let { x, y, ...z } = { x: 1, y: 2, a: 3, b: 4 }
console.log(x) // 1
console.log(y) // 2
console.log(z) // 3

Я так понимаю, в z будет {a: 3, b:4}, а не 3?
Жизнь на Земле жила и развивалась при естественном фоне космических излучений. И плавно приспосабливалась. Люди изменили условия за короткий промежуток времени. И почему это будет иметь положительное влияние, если равновесие нарушено столь быстро?
Достаточно даже просто внимательного чтения документации.
Это такая ирония, что он помощника назвал Jarvis. Прям Тони Старк нашей реальности: и ИИ запрограммирует, и мини-коллайдер уровнем выровняет. Я шапочку из фольги не надеваю. Но уж больно это на пиар-компанию похоже.
«Влажные мечты» компаний. Все пытаются поднять хайп. А простые обыватели только смотрят на зарплаты.
Ну не будут все поголовно программировать! Работа для людей технического склада ума. Плюс сопряжена с рядом недостатков, как то: малоподвижный образ жизни, усталость глаз, умственное и нервное напряжение. Я не говорю, что это особенности только этой профессии. Но не каждый на это пойдет.
Да и сама работа должна нравиться. Как будто мало профессий умственного труда.
Как обычно вопрос состоит не в том, что лучше, а в том, что целесообразнее.
Всегда найдутся как плюсы, так и минусы. В случае с хранением логики в БЖ мы можем получить, например, большую производительность. Но тогда мы привязываемся к данной конкретной БД.
А за статью спасибо! Именно такого рода статьи должны быть на хабре.
Очень полезный материал!
… Нееет! © Борат
Истина всегда где-то посередине…
Программит — это только профессия или хобби. Это не характер, не склад ума, не умение общаться в конце концов.

Информация

В рейтинге
Не участвует
Откуда
Минск, Минская обл., Беларусь
Дата рождения
Зарегистрирован
Активность