Я уже рассказывал про свой UI фреймворк Chorda в предыдущей статье. Интереса он (ожидаемо) не вызвал, но остался как полигон для испытания идей и подходов, которые кажутся мне интересными.

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

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

Как удалось исправить ситуацию и что в итоге получилось можно узнать, заглянув под кат

Мы используем TypeScript, потому что это делает разработку безопаснее и быстрее.

Но, на мой взгляд, TypeScript из коробки содержит слишком много послаблений. Они помогают сэкономить немного времени JavaScript-разработчикам при переходе на TS, но съедают очень много времени в долгосрочной перспективе.

Я собрал ряд настроек и принципов для более строгого использования TypeScript. К ним нужно привыкнуть один раз — и они сэкономят массу времени в будущем.

Поддержка Typescript, без сомнения, была самой желанной и востребованной фичей в течении долгого времени и вот она здесь: Svelte официально поддерживает TypeScript!

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

Этим летом мы с Ромой запустили серию твитов с полезными советами и приемами по Angular. Сообщество тепло встретило эту инициативу, и я решил написать обобщающую статью.

Вот мои 5 рекомендаций, которыми хочется поделиться с разработчиками. Эти советы будут подкреплены конкретными примерами из моего твиттера. Они помогут вам поднять свои навыки или как минимум дадут пару практических приемов.

Привет! Меня зовут Иван Греков, я работаю UI-разработчиком в frontend-команде Badoo. Главные задачи нашей команды — создание новых и поддержка существующих пользовательских интерфейсов для сайтов и приложений Badoo и Bumble. 

Когда в конце 2019 года мы начали параллельно работать над несколькими проектами, мы задумались над повышением стабильности кода и возможностью его многократного использования. Для этого мы решили переписать наши 630 React UI-компонентов на TypeScript. Я расскажу о том, как мы работали над ними без перерыва в доставке фич и как организовали поэтапный переход на TypeScript для UI-разработчиков, которым этот язык был в новинку.

Не так давно я опубликовал статью о CLI для React-компонент, который для меня стал первым публичным npm-пакетом. И так как мне хотелось поделиться своими наработками с как можно большим кругом разработчиков я начал изучать разные способы улучшения своей позиции в поисковой выдаче на разных специализированных сайтах. В попытках улучшить свое положение я опирался на поиск в npm, yarn и npms. И если вы сейчас откроете страничку моего пакета в любом из этих трех сайтов, то результаты там будут, к сожалению, скромными и я попробую объяснить почему и порассуждаю на эту тему.

Всем привет!

В этой статье, я хочу вам рассказать о том, как так получилось, что мне пришлось писать свой CLI генерации React компонент, притом, что готовых решений достаточно много.

Нет, я не болен. По крайней мере так говорит голос в моей голове. Я наркоман. Вот уже более 15 лет я сижу на игле. Употребляю много, жёстко, до обморочного состояния. Докатился до того, что в последнее время не стесняюсь ни друзей, ни жены, ни детей… Двоих детей! Не люблю бадяженый, люблю чистый, без примесей. За годы перепробовал многое, но в последнее время остановился в поисках. Забавно осознавать, что от одного и того же получаешь одновременно и боль, и радость. Мне бы в лечебку, я даже хочу, я даже знаю в какую. Знаете такие, где продолжаешь употреблять, но под присмотром?

Angular i18n

Цель статьи — это описать детальные шаги интернационализации вашего приложения на Angular с помощью родного функционала.

На входе мы имеем коммерческое приложение. Как традиционно положено сначала сделали, запустили, а потом решили что ой, у нас же есть другие рынки, нужно срочно перевод сделать. Обычная история, пальцев рук не хватит посчитать сколько раз такое было. Но так же все знают что решения по интернационализации необходимо закладывать в архитектуру приложения с самого начала, потому что потом очень тяжело добавить i18n в готовое приложение. Но все же...

ЗTypeGraphQL v1.0

Допустим, перед вами стоит задача написать фронтенд-приложение. Есть ТЗ с описанием функционала, тикеты в баг-трекере. Но выбор конкретной архитектуры лежит на вас.

Порой трудно заранее понять, какая архитектура будет удачной, а какая нет. Особую сложность представляет организация управления состоянием. Как лучше всего хранить и синхронизировать данные, которые нужно отображать? Каждый по-своему подходит к решению этой проблемы и либо пишет весь код сам, либо берет готовую библиотеку. Любой из этих способов — со своими плюсами и минусами.

В статье я расскажу о своем решении проблемы управления состоянием на примере разных стадий развития приложения.

В этой статье я хочу рассказать об алгоритме, который помогает ответить на извечный вопрос всех проектов:

Когда проект будет закончен?

Более формально проблема звучит так: "Проект состоит из задач, которые могут зависеть друг друга, а также могут иметь один и тех же исполнителей. Когда проект может быть закончен?"