Ну вот, есть флаг компилятора, любители строгой типизации могут быть частично довольны.
На практике, за много лет работы на крупных TypeScript-проектах, я, пожалуй, ни разу не сталкивался с вышеупомянутой ошибкой из-за выхода за границу массива.
Просто мне кажется, не стоит превращать TypeScript в Java, это не ускорит разработку. Хотите все плюшки строгой типизации - Java/C# + WebAssembly в руки, и вперёд :)
Естественно, теперь getItem возвращает только string, а как иначе? Хотите безопасную работу с null/undefined? createCache<string|null|undefined> (либо ваше решение, с встроенным undefined)
Хотите кеш с любыми типом значений? createCache<unknown>
Хотите выбрасывать ошибку для отсутствующих элементов? Добавьте проверку в реализацию методов.
Кроме того, в TypeScript есть куча настроек для уровня строгости типизации, просто далеко не все согласны выкручивать всё на максимум. Имхо, проблема высосана из пальца
Как человек с дипломом магистра в компьютерной инженерии, могу согласиться с тем, что сам диплом не даёт ничего (если это не какая-нибудь "Лига Плюща"). Но учёба дала многое, систематизировала знания. Не то, чтобы это всё нельзя было выучить самому и в два раза быстрее - можно, только я был бы как тот ёжик в тумане... Плюс, многие темы были такие низкоуровневые (карты Карно, микроконтроллеры, ассемблер, компьютерные сети), что я бы в жизни сам не стал их учить. На практике они вряд ли нужны фронтенд разработчику, но для общего развития и глубокого понимания работы компьютера очень помогли.
Стоит добавить, что JS я начал учить самостоятельно ещё на первом курсе, и со второго курса начал работать на полставки (а потом и full-time). В итоге после выпуска у меня было уже 3 года опыта. Без самообразования знаний из универа было бы недостаточно, чтобы начать работать.
И ещё, магистратура, имхо, не дала мне абсолютно ничего. Бакалавриат дал.
Всё равно некорректно: "... задавали на собеседовании и другие джуны". Ну не строятся так предложения в русском языке. "Задавали рекрутеры и другие джуны" - вот так валидно.
Кто-нибудь уже прокомментировал заголовок статьи? Возьму это на себя :)
Чуть три раза голову не сломал, пока понял суть заголовка. Вас спрашивали вопросы? Вопросы и другие джуны? Другие джуны на собеседованиях? Джуны уже проводят собеседования? x_x
Чтоб не быть совсем деструктивным, предложу пару альтернативных вариантов:
Вопросы, которые мне задавали интервьюеры и коллеги
Статья интересная, но немного затянутая, на мой взгляд.
В 1910 году был синтезирован нейротрансмиттер «дофамин», а в 2000 году Арвиду Карлссону за исследования о важнейшей роли данного гормона в деятельности мозга...
Хотел придраться к этой фразе, где дофамин назван нейротрансмиттером и гормоном в одном предложении, но погуглил, и понял, что эта неразбериха везде, даже в Википедии. А ведь это разные вещи, по идее. Нейротрансмиттеры выделяются нейронами в нервных тканях, и работают быстро и локально; тогда как гормоны выделяются железами в кровь, разносятся по всему организму и работают дольше.
Но даже не цепляясь к терминологии, я считаю такой подход к объяснению проведения людей слишком упрощённым и притянутым за уши. Это близко к бихевиористской теории Скиннера, которая пытается всё многообразие людского поведения и взаимодействия с окружающими обосновать чисто механическим поощрением или наказанием в виде выброса химических веществ в организме. Современная психология далеко ушла с тех пор, и хотя бихевиоризм всегда играет свою роль, он объясняет далеко не всё. В эту тему очень советую почитать книгу Альфи Кона "Наказание наградой", чтоб взглянуть на вопрос мотивации людей (в т.ч. сотрудников) с совершенно другой стороны.
Хорошо изложено. Согласен насчёт boilerplate-кода - это прямо беда.
И вот тут Redux подводит - то, что должно быть цельным внутри компонента, оказывается размазанным по множеству файлов и сущностей - получаем Low cohesion вместо High. Связи, которые должны оставаться внутри, выходят наружу
Вот с этим не могу согласиться. Основная идея центрального хранилища в том, чтобы обеспечить единый источник информации (source of truth), которая нужна в разных компонентах или даже в разных модулях. Redux отлично подходит для глобального стейта. Он также вполне позволяет изолировать часть состояния и его логику на уровне модуля. Ну а если какая-то логика и состояние нужны только в одном компоненте - используйте для этого внутренний стейт компонента. Не нужно всё локальное пихать в store - это и сам Дэн Абрамов, по-моему, советовал.
Ну а множество файлов - это неплохо, если файлы, относящиеся к одному модулю, лежат рядом в одной папке - так мы избегаем файлов на сотни строк кода, как часто бывало с WinAPI. К тому же, Redux Toolkit смягчает эту проблему, объединяя объявление экшнов и редьюсеров с помощью "слайсера" в одном файле.
А в чём принципиальное отличие этой реализации от Babel?
Наследование статических полей — точно так же, методом Object.setPrototypeOf.
Наследование динамических полей — точно так же, методом d.prototype = Object.create(b).
Ссылка на супер-класс так же подменяется во время компиляции.
Смысл тот же, просто чуть больше проверок на редкие крайние случаи.
Ну вот, есть флаг компилятора, любители строгой типизации могут быть частично довольны.
На практике, за много лет работы на крупных TypeScript-проектах, я, пожалуй, ни разу не сталкивался с вышеупомянутой ошибкой из-за выхода за границу массива.
Просто мне кажется, не стоит превращать TypeScript в Java, это не ускорит разработку. Хотите все плюшки строгой типизации - Java/C# + WebAssembly в руки, и вперёд :)
Я что-то не догоняю... Вы же явно указали тип string для элементов кеша:
Естественно, теперь getItem возвращает только string, а как иначе? Хотите безопасную работу с null/undefined?
createCache<string|null|undefined> (либо ваше решение, с встроенным undefined)Хотите кеш с любыми типом значений?
createCache<unknown>Хотите выбрасывать ошибку для отсутствующих элементов? Добавьте проверку в реализацию методов.
Кроме того, в TypeScript есть куча настроек для уровня строгости типизации, просто далеко не все согласны выкручивать всё на максимум. Имхо, проблема высосана из пальца
Почему же, мемчик про Rockstar Developer - зачотный :)
Выглядит интересно, спасибо!
Вопрос: как обстоят дела с поддержкой разными браузерами? (пошёл гуглить сам, но это стоило бы упомянуть в статье)
Как человек с дипломом магистра в компьютерной инженерии, могу согласиться с тем, что сам диплом не даёт ничего (если это не какая-нибудь "Лига Плюща"). Но учёба дала многое, систематизировала знания. Не то, чтобы это всё нельзя было выучить самому и в два раза быстрее - можно, только я был бы как тот ёжик в тумане... Плюс, многие темы были такие низкоуровневые (карты Карно, микроконтроллеры, ассемблер, компьютерные сети), что я бы в жизни сам не стал их учить. На практике они вряд ли нужны фронтенд разработчику, но для общего развития и глубокого понимания работы компьютера очень помогли.
Стоит добавить, что JS я начал учить самостоятельно ещё на первом курсе, и со второго курса начал работать на полставки (а потом и full-time). В итоге после выпуска у меня было уже 3 года опыта. Без самообразования знаний из универа было бы недостаточно, чтобы начать работать.
И ещё, магистратура, имхо, не дала мне абсолютно ничего. Бакалавриат дал.
Всё равно некорректно: "... задавали на собеседовании и другие джуны". Ну не строятся так предложения в русском языке. "Задавали рекрутеры и другие джуны" - вот так валидно.
Кто-нибудь уже прокомментировал заголовок статьи? Возьму это на себя :)
Чуть три раза голову не сломал, пока понял суть заголовка. Вас спрашивали вопросы? Вопросы и другие джуны? Другие джуны на собеседованиях? Джуны уже проводят собеседования? x_x
Чтоб не быть совсем деструктивным, предложу пару альтернативных вариантов:
Статья интересная, но немного затянутая, на мой взгляд.
Хотел придраться к этой фразе, где дофамин назван нейротрансмиттером и гормоном в одном предложении, но погуглил, и понял, что эта неразбериха везде, даже в Википедии. А ведь это разные вещи, по идее. Нейротрансмиттеры выделяются нейронами в нервных тканях, и работают быстро и локально; тогда как гормоны выделяются железами в кровь, разносятся по всему организму и работают дольше.
Но даже не цепляясь к терминологии, я считаю такой подход к объяснению проведения людей слишком упрощённым и притянутым за уши. Это близко к бихевиористской теории Скиннера, которая пытается всё многообразие людского поведения и взаимодействия с окружающими обосновать чисто механическим поощрением или наказанием в виде выброса химических веществ в организме. Современная психология далеко ушла с тех пор, и хотя бихевиоризм всегда играет свою роль, он объясняет далеко не всё. В эту тему очень советую почитать книгу Альфи Кона "Наказание наградой", чтоб взглянуть на вопрос мотивации людей (в т.ч. сотрудников) с совершенно другой стороны.
Этот комментарий тянет на отдельную статью, и очень дельную
Хорошо изложено. Согласен насчёт boilerplate-кода - это прямо беда.
Вот с этим не могу согласиться. Основная идея центрального хранилища в том, чтобы обеспечить единый источник информации (source of truth), которая нужна в разных компонентах или даже в разных модулях. Redux отлично подходит для глобального стейта. Он также вполне позволяет изолировать часть состояния и его логику на уровне модуля. Ну а если какая-то логика и состояние нужны только в одном компоненте - используйте для этого внутренний стейт компонента. Не нужно всё локальное пихать в store - это и сам Дэн Абрамов, по-моему, советовал.
Ну а множество файлов - это неплохо, если файлы, относящиеся к одному модулю, лежат рядом в одной папке - так мы избегаем файлов на сотни строк кода, как часто бывало с WinAPI. К тому же, Redux Toolkit смягчает эту проблему, объединяя объявление экшнов и редьюсеров с помощью "слайсера" в одном файле.
Наследование статических полей — точно так же, методом
Object.setPrototypeOf.Наследование динамических полей — точно так же, методом
d.prototype = Object.create(b).Ссылка на супер-класс так же подменяется во время компиляции.
Смысл тот же, просто чуть больше проверок на редкие крайние случаи.
Выглядит аналогично реализации Babel.