Если вы, до того, как заинтересовались JavaScript, писали на традиционных языках с сильной типизацией, то вы, возможно, знакомы с концепцией void. Это — тип, использование которого сообщает программисту о том, что соответствующие функции и методы при их вызове ничего не возвращают.



Сущность void имеется также в JavaScript и TypeScript. В JS это — оператор. В TS это примитивный тип данных. И там и там void ведёт себя не так, как могли бы ожидать многие из тех, кто сталкивался с void в других языках.

Всем, кому приходилось вставлять HTML содержимое в DOM в Angular, доводилось видеть это сообщение. Конечно, все мы получаем проверенное содержимое с нашего же сервера и просто хотим застилизовать сообщение об ошибке. Или вставляем HTML из наших же констант, инлайним наши SVG иконки, ведь нам всего лишь нужно покрасить их в цвет текста. Ведь ничего плохого не случится, если мы просто скажем Angular`у — не дрейфь, там всё чисто.

Чаще всего это может быть и так, но в крупных проектах с массой разработчиков, которые пишут независимые компоненты, никогда не знаешь наверняка, где может оказаться твой код. А если вы, как я, разрабатываете библиотеку переиспользуемых компонентов, то подобную ситуацию нужно решить на корню.

5 лет назад, после поиска годного решения в RxJs, Beacon, ...etc.js, и остановившись на flyd.js и написал 4-6 проектов используя только три фичи из либы stream, on, combine. Остальное оказалось не у дел, хотелось легкости бандла. Так появился alak, первые версии до 0.3 были всего 20-30 строк и полностью заменили flyd.

Год спустя появилась версия 0.4 уже на 72 строки с паттерн матчингом и mix (аналог combine из flyd или computed из vue). Спустя три года и десятки проектов — появилось ощущение годности делится опытом и релизить 1.0.

Привет, Хабр. Это статья о том как написать Hello world по последнему слову техники.

В конце мы получим hello world библиотеку которая:

• Использует typescript
• Заботится о codestyle
• Генерирует доку
• Проводит тесты

Введение

В данной статье хотел бы поделиться своими эмоциями и приобретенными навыками в разработке первого REST API на Node.js с использованием TypeScript, как говорится, с нуля. История достаточно банальная: «Закончил университет, получил диплом. Куда же пойти работать?» Как можно было догадаться меня проблема не обошла стороной, пусть думать особо и не пришлось. Позвал к себе на стажировку разработчик (выпускник той же специальности). Полагаю, что это достаточно распространенная практика и существует множество подобных историй. Я, недолго думая, решил попробовать свои силы и пошел…

День первый. Знакомство с Node.js

Пришёл я на back-end разработку. В данной IT-компании используют платформу Node.js, с которой я абсолютно не был знаком. Я немного убежал вперед, забыв рассказать читателю, что никогда и ничего не разрабатывал на JavaScript (за исключением пары скриптов с копированным кодом). Алгоритм работы и архитектуру веб-приложений в целом я понимал, так как разрабатывал CRUD на Java, Python и Clojure, но этого было недостаточно. Поэтому первый день я полностью посвятил изучению Node.js, очень помог этот скринкаст.

Параллельно изучая веб-фреймворк Express, менеджер пакетов npm, а также такие файлы как package.json и tsconfig.json, голова просто шла кругом от количества информации. Очередной урок, что усвоение всего материала одновременно задача близкая к невозможной. К концу дня я все же справился с настройкой окружения и смог запустить express веб-сервер! Но радоваться было рано, потому что уходил домой с полным ощущением непонимания. Чувство, что я утопал в огромном мире JS не покидало меня ни на минуту, поэтому необходима была перезагрузка.

В этой статье мы рассмотрим настройку React Native окружения с использованием expo-cli, Typescript, и Jest.

Typescript поможет нам избежать ошибок при разработке и написать более эффективное мобильное приложение.

Современные разработки позволяют интегрировать Typescript в окружение разработки. Так же мы можем использовать VS Code, который отлично поддерживает Typescript.

Также интеграция с React Native даст нам возможность использовать сервис автодополнения, навигацию по коду и рефакторинг.

Expo — это набор инструментов, которые упрощают создание нативных React приложений. В этом уроке я собираюсь показать вам, как вы можете быстро создавать нативные React приложения, используя Expo.

Flexibile form (fform) — построитель форм с минимальной избыточностью кода, при этом максимально гибкий и расширяемый. Используемый стэк технологий: React (v16), Redux (опционально), JSONSchema, TypeScript. Основная идея — максиально возможное повторное использование схем, компонентов и функций.

Здравствуйте, меня зовут Дмитрий Карловский и я иногда выступаю на конференциях, митапах, а так же с недавних пор сам вхожу в команду организаторов одного из них — PiterJS. Недавно у нас был юбилей — 40 проведённых митапов. Но вместо того, чтобы расслабиться и получать поздравления, мы запарились и сами подготовили доклады от организаторов.

Но и этого нам мало, поэтому мы решили отметить юбилей по крупному, организовав конференцию на берегах Невы PiterJSConf, которая пройдёт уже в эту субботу 7 сентября 2019. Спешите записываться, пока ещё есть свободные места, ведь участие в ней для вас будет совершенно бесплатно.

Мы всё это делаем не за деньги, а за великую идею, что знания должны быть бесплатны. Поэтому всё, что мы делаем, доступно в Open Source. Мы с радостью делимся своими наработками, знаниями и опытом с другими. И призываем к сотрудничеству организаторов из других городов для создания открытой платформы организации технологических митапов на регулярной основе. Присоединяйтесь к нам в качестве организатора, партнёра, докладчика, волонтёра, патрона или просто слушателя.

А пока, предлагаю вам рассказ про веб приложение для проведения презентаций $hyoo_slides, которое я использую для всех своих выступлений. Видеозапись доступна на YouTube, но там не всё. Можете читать этот рассказ как статью, так и открыть в интерфейсе самого приложения. Далее я расскажу вам, сколько всего оно умеет, и как работает.

TypeScript — поистине прекрасный язык. В его арсенале есть все, что необходимо для качественной разработки. И если вдруг, кому-то знакомы секс-драматические этюды с JavaScript, то меня поймет. TypeScript имеет ряд допущений, неожиданный синтаксис, восхитительные конструкции, которые подчеркивают его красоту, форму и наполняют новым смыслом. Сегодня речь о них, об этих допущениях, о магии выражений. Кому интересно, добро пожаловать.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Understanding @Input, @Output and EventEmitter in Angular» автора foolishneo.

Приветствую всех желающих накапливать информацию о тонкостях работы фреймворка Angular.

Сегодня посчитал нужным лучше изучить информацию, касающуюся организации взаимодействия между компонентами Angular и начать практиковать переводы интересующих меня статей с английского.

Надеюсь найдутся те, для кого перевод статьи с Medium будет полезен.

Давно имея желание начать переводить полезные статьи с английского, решил начать с простенькой, весьма не объемной, но возможно, дополняющей имеющиеся знания статейки. К Вашему вниманию, господа…

Автор статьи, перевод которой мы сегодня публикуем, говорит, что источником вдохновения для её написания послужил этот пост и комментарии к нему. По его словам, IT-специалисты имеют неправильные представления о типах, используют некорректную терминологию и, обсуждая вопросы, связанные с типами, приходят к ошибочным выводам. Он отмечает то, что не является защитником статической системы типов. Единственное, что его беспокоит — это правильное использование терминов. Это позволяет вести конструктивные дискуссии. Автор говорит, что написал этот материал спонтанно, но надеется на то, что в нём нет ошибок. Если же он что-то и напутал — он просит дать ему об этом знать.



Давайте раз и навсегда разберёмся во всём том, что вызывает неразбериху при разговорах о системах типов.

Активные пользователи Телеграма, особенно те, кто подписан на Павла Дурова, наверняка что-то слышали о том, что Телеграм проводил в этих ваших интернетах конкурс для iOS, Android и JavaScript разработчиков, а также для дизайнеров. Несмотря на то, что это было довольно эпичное событие с раздачей солидных призов (один из участников получил 50к долларов за первое место, написав самое быстрое и лёгкое приложение для Android), о нём как-то слабо писали, во всяком случае в Рунете. Своим дебютным постом попробую исправить ситуацию.

JavaScript – это один из языков с динамической типизацией. Такие языки удобны для быстрой разработки приложений, но когда несколько команд берутся за разработку одного большого проекта, лучше с самого начала выбрать один из инструментов для проверки типов.

Можно начать разрабатывать код на TypeScript или включить в проект Flow. TypeScript – это компилируемая версия JavaScript, разработанная компанией Microsoft. Flow, в отличие от TypeScript, это не язык, а инструмент, который позволяет анализировать код и проверять типы. В сети можно найти множество статей и видео об этих подходах, а также руководство по тому, как начать использовать типизацию. В этой статье мы бы хотели рассказать, почему нам не подошел Flow, и как мы начали переходить на Typescript.

В этой статье будет использоваться ГРЯЗНЫЙ, небезопасный, "костыльный", страшный и т. д. метод eval. Слабонервным не читать!

Сразу скажу, что некоторые проблемы удобства использования решить не удалось: в коде, который будет передан в worker, нельзя использовать замыкание.

Привет!

У нас в БКС есть админка и множество форм, но в React-сообществе нет общепринятого метода — как их проектировать для переиспользования. В официальном гайде Facebook’a нет подробной информации о том, как работать с формами в реальных условиях, где нужна валидация и переиспользование. Кто-то использует redux-form, formik, final-form или вообще пишет свое решение.

В этой статье мы покажем один из вариантов работы с формами на React. Наш стек будет вот таким: React + formik + Typescript. Мы покажем:

• Что компонент должен делать.
• Конфиг, поля и валидация на уровне пропсов.
• Как сделать форму переиспользуемой.
• Оптимизацию перерендера.
• Чем наш способ неудобен.

При новой бизнес-задаче мы узнали, что нам нужно будет сделать 15-20 похожих форм, и гипотетически их может стать еще больше. У нас была одна форма-динозавр на конфиге, которая работала с данными из `store`, отправляла actions на сохранение и выполнение запросов через `sagas`. Она была замечательной, выполняла бизнес-велью. Но уже была нерасширяемой и непереиспользуемой, только при плохом коде и добавлении костылей.

Задача поставлена: переписать форму для того, чтобы ее можно было переиспользовать неограниченное количество раз. Хорошо, вспоминаем функциональное программирование, в нем есть чистые функции, которые не используют внешние данные, в нашем случае `redux`, только то, что им присылают в аргументах (пропсах).

И вот что получилось.

Всё больше и больше проектов и команд используют TypeScript. Однако просто применять TypeScript и выжимать из него максимум пользы — это очень разные вещи.

Представляю вам список высокоуровневых передовых практик использования TypeScript, которые помогут получить максимум преимуществ от применения этого языка.

Если вы занимаетесь frontend разработкой, то наверняка вам знакома следующая мизансцена: сроки по проекту стремительно сжимаются, ваше руководство, или заказчик, а-то и оба вместе желают увидеть глазами работающее приложение прямо сейчас, пусть и с ненастоящими данными. При этом back, возможно, и есть, но именно api слой взаимодействия с front'ом отсутствует от слова совсем.

Итак, недавно я столкнулся с такой ситуацией, и я разрабатываю frontend под angular (сидящие вокруг на стульях люди вяло похлопали, кто-то понимающе кивнул).

Теперь попробую серьезно. С одной стороны ситуация нередкая, и решений может быть выбрано много.

В голову приходило несколько вариантов решения:

1. Захардкодить данные на уровне компонент
2. Захардкодить данные на уровне resolver сервисов, приколотить их к нужным роутам
3. Захардкодить данные на уровне сервисов поставщиков данных
4. Запилить api, и, согласно оговоренным контрактам, возвращать захардкоженные данные

17 ноября 2018 года. Нас четверо. Настроение у всех приподнятое — прошли первый этап ШРИ, Школы разработки интферфейсов. Он состоял из лекций и домашних заданий: осваивали разные фронтендерские и околофротендерские технологии, инструменты, Скрам. Знали, что всё это придётся применять в боевом проекте на втором этапе. Но одно дело знать, и другое — действительно реализовать этот проект за ближайшие 5 недель.

Мотивом для написания данной статьи послужила другая статья на тему типизации Vue и, соответственно, Vuex. К моему удивлению я не обнаружил там упоминания модуля, который, по моему мнению, является лучшим в своем роде «типизатором» Vuex. Поиск по Хабру, да и вообще по Рунету (на самом деле и в англоязычных источниках не просто сходу найти какие-либо упоминания), увы, не дал никаких результатов. Данная статья не является подробным разбором и многостраничным мануалом по использованию и настройке, но скорее способом поделиться с вами, уважаемые Vue-ниндзя, инструментом, который отлично справляется со своей задачей.

Команда TestMace снова с вами. На этот раз мы публикуем перевод статьи о преобразовании кода TypeScript, используя возможности компилятора. Приятного чтения!

Введение

Это мой первый пост, и в нём мне бы хотелось показать решение одной задачи с помощью API компилятора TypeScript. Чтобы найти это самое решение, я долгое время копался в многочисленных блогах и переваривал ответы на StackOverflow, поэтому, чтобы уберечь вас от такой же участи, я поделюсь всем тем, что я узнал о таком мощном, но слабо документированном наборе инструментов.