Да, к сожалению этот способ не решает полностью проблемы. И проверить все нельзя, и типы в массивах не проверишь (там просто нет метаданных), и много чего еще. Это не решение всего, скорее исследование что вообще можно сделать простыми средствами.
Насчет noImplicitAny — да, однозначно. Вот только — часто вы видели такое? куча библиотек используют any и выдают их в качестве результата. а иногда я вообще вижу конструкции типа: smth as any as unknown.
Согласно вики, Андерс Хейлсберг (дат. Anders Hejlsberg; род. 2 декабря 1960, Копенгаген)[2] — датский инженер-программист. Создатель Turbo Pascal, Delphi, C# и TypeScript.
Так что скорее всего я не ошибся, просто не указал 100% фактов, так как цели этой и не ставил,
Конечно, я мог допустить неточности. Буду признателен, если вы в конструктиве допишете в коментах достоверные факты.
может быть, я что-то сам запамятовал про .NET. мне казалось, что там все равно больше возможностей доступа к объекту, но возможно вы правы. не проверял к сожалению
Никита, спасибо за статью! Оно заставляет подумать, крепко подумать. Я обычно жалуюсь на наличие или чрезмерное количество фреймворков. Но ведь и в своем коде может быть больше абстракций, чем нужно конкретной задаче.
Пару месяцев назад к нам приходил программист собеседоваться. Невероятно умный. вот просто гений. он ответил на 100% каверзных вопросов про Javascript. но когда я попросил его обрисовать общую схему, как бы он простой бекенд на ноде делал, он сказал — ну как, один файл, там роутер и сразу обработку — достали из базы и вернули. я такой — а как же слои там, все дела? Он — так задачи не стояло сделать что-то расширяемое. Надо было просто решить задачу. Если там появится еще что-то — тогда типа и буду делать слои. а без необходимости — какой смысл?
Я не могу прям 100% с этим согласиться, но некоторое рациональное зерно в этом есть
да, к сожалению у Typescript как и у Javascript есть свои ограничения. но тем не менее, это удобнее чем размещать сами настройки валидации вдали от класса. а так, я полностью согласен. иметь всю валидацию в объекте сразу при присвоении значения было бы много круче. но это уже .NET
Я написал в самом начале, что это не сравнений альтернатив. Я не ставил себе такой задачи. Модуль интересный, часто используемый. Я его применял практически во всех проектах с Ангуляром.
Приведено как раз типовое использование модуля, плюс пара кейсов — как инициализировать язык, и как использовать сервис локализации в TS коде, когда данные могли еще не прогрузиться. Это вот небольшая особенность.
Плюс я привел пример, как поддерживать файлы JSON в консистентном состоянии. Мне это очень помогло в одном из проектов, где было 4+ языков, причем часть арабских.
Но спасибо большое за комментарий, я обязательно учту это к следующей статье!
Спасибо за комментарий. насколько я помню, в моих проектах с локализацией мне не приходилось чего-то особенного делать для AOT режима. хотя да, JSON не включался в бандл. В принципе, я не вижу причины его включать. Скажем, у вас 10 языков. Скорее всего пользователь будет использовать 2-3 в лучшем случае — скачает только то, что необходимо.
Я чувствую что-то сходное, и отчасти это и послужило мотивацией вспомнить историю и истоки аджайла, сами идеи, которые были вложены. Сейчас идет некоторая подмена ценностей, многие просто берут что-то на поверхности, формальные признаки скрама, ценность резальтата побыстрее и понеслось. Отсюда и негатив, потому что это лишь внешние факторы без существенного содержания.
Абсолютно с вами согласен насчет чертежа — много лет это действительно отличный инструмент, так как в нем есть формальные правила, с которыми все согласны. Тут вопрос скорее в другом — что было в голове у главного инженера, когда он создавал этот чертеж? и является ли он действительно отображением того, что он хотел сделать.
Ну да Бог с ним. Насчет программистов. Вроде бе подробное ТЗ, составленное аналитиков, с описанием форм, входных и выходных данных является примерно таким же формальным и относительно точно интерпретируемым «чертежом». Особенно если еще дополнено графическим дизайном. И следуя этому, программист сделает то, что от него «хотели». вопрос, который я в статье затрагиваю, и из-за которого, как мне думается, и появился манифест agille — а что на самом деле хотели сделать?
между двумя программистами наиболее эффективно, после того как словами обсудили идею, описать приницпиальную схему модулей программы (приложения), интерфейсы REST Api в чем-то формальном (Postman, Swagger), с указанием всех входных и выходных данных. если проект позволяет такое сделать — это очень здорово. Мы стараемся в своих проектах это применять
Я думаю, что общие принципы применимы везде — с заказиком ли вы работаете, или внутри команды. Несколько каналов коммуникации — вживую, голосом, подтвердили письменно. Итеративно проверять, что поняли друг друга верно, часто показывать друг другу работу, делать код ревью и прочее. Ну и стараться сами команды, конечно же, строить из людей, подходящих друг другу, насколько это возможно
Спасибо за инфу! цель была чутка не в том, но этот вызов удобно было бы использовать для тестирования по крайней мере. Моя проблема была в том, что wkhtmltopdf (вернее тот html движок, который он использует) разбирает HTML и CSS по своему, отлично от хрома.
Насчет noImplicitAny — да, однозначно. Вот только — часто вы видели такое? куча библиотек используют any и выдают их в качестве результата. а иногда я вообще вижу конструкции типа: smth as any as unknown.
Так что скорее всего я не ошибся, просто не указал 100% фактов, так как цели этой и не ставил,
Конечно, я мог допустить неточности. Буду признателен, если вы в конструктиве допишете в коментах достоверные факты.
Пару месяцев назад к нам приходил программист собеседоваться. Невероятно умный. вот просто гений. он ответил на 100% каверзных вопросов про Javascript. но когда я попросил его обрисовать общую схему, как бы он простой бекенд на ноде делал, он сказал — ну как, один файл, там роутер и сразу обработку — достали из базы и вернули. я такой — а как же слои там, все дела? Он — так задачи не стояло сделать что-то расширяемое. Надо было просто решить задачу. Если там появится еще что-то — тогда типа и буду делать слои. а без необходимости — какой смысл?
Я не могу прям 100% с этим согласиться, но некоторое рациональное зерно в этом есть
Приведено как раз типовое использование модуля, плюс пара кейсов — как инициализировать язык, и как использовать сервис локализации в TS коде, когда данные могли еще не прогрузиться. Это вот небольшая особенность.
Плюс я привел пример, как поддерживать файлы JSON в консистентном состоянии. Мне это очень помогло в одном из проектов, где было 4+ языков, причем часть арабских.
Но спасибо большое за комментарий, я обязательно учту это к следующей статье!
Ну да Бог с ним. Насчет программистов. Вроде бе подробное ТЗ, составленное аналитиков, с описанием форм, входных и выходных данных является примерно таким же формальным и относительно точно интерпретируемым «чертежом». Особенно если еще дополнено графическим дизайном. И следуя этому, программист сделает то, что от него «хотели». вопрос, который я в статье затрагиваю, и из-за которого, как мне думается, и появился манифест agille — а что на самом деле хотели сделать?
между двумя программистами наиболее эффективно, после того как словами обсудили идею, описать приницпиальную схему модулей программы (приложения), интерфейсы REST Api в чем-то формальном (Postman, Swagger), с указанием всех входных и выходных данных. если проект позволяет такое сделать — это очень здорово. Мы стараемся в своих проектах это применять