Привет. Я работаю в команде, занимающейся улучшением пользовательского опыта
при работе с деньгами. Front-end мы поставляем npm-пакетами.
В какой-то момент я столкнулся с проблемами, которые привели меня к использованию
поля exports в package.json
Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры "дергают" бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.
За 7 лет я как поддерживал множество legacy API, так и разрабатывал c нуля. И я поработал, наверное, с большинством стратегий по возвращению ошибок, но каждая из них создавала дискомфорт в той или иной мере. В последнее время я нащупал оптимальный вариант, о котором и хочу рассказать, но с начала расскажу о двух наиболее популярных вариантах.
В процессе эволюции нашей библиотеки компонентов Taiga UI мы стали замечать, что некоторые компоненты посложнее имеют @Input просто для того, чтобы прокинуть его значение в @Input другого нашего базового компонента внутри себя. Иногда встречается такая вложенность даже в три слоя.
Мы справились с помощью хитрых директив, которые назвали контроллерами. Они полностью решили проблему вложенности и сократили вес библиотеки.
В этой статье я покажу, как мы организовали общую систему настроек всех полей ввода благодаря этой концепции и возможностям DI в Angular.
Утверждают, что прямо сейчас с помощью no-code инструментов не создать сколько-нибудь серьезный продукт. Скептики, к коим относится большинство программистов, считают это невозможным в принципе. На самом дела, за продуктами «без кода» сейчас называют то, что раньше было обычными электронными таблицами и конструкторами сайтов из кубиков.
Скептики как будто правы: этот no-code не заменяет код – не реализует алгоритм, то есть ветвления циклы и прочее, а только позволяет накидать на чистый лист квадратики, которые как-то там взаимодействуют друг с другом. Элементы платежных систем, фрагменты веб-документов, формы и чаты, таблицы с фильтрами. Всё это связывается в пёструю мешанину MVP и гордо именуется no-code решением.
Давайте попробуем что-то чуть сложнее, чем аппликацию готовых блоков – с нуля сделаем, например, проводку документа поступления товаров и услуг. Пересчитаем остатки на складах и средневзвешенную себестоимость, обновим сальдо договора и, наконец, пометим документ проведенным. Без написания алгоритма на языке программирования.
В этой статье я опишу различные техники повторного использования кода и разбиения сложных объектов на части, с которыми я столкнулся. Постараюсь объяснить, почему классическое наследование, а также некоторые другие популярные подходы не работают в сложных случаях, и какие есть альтернативы.
Будет рассказано о декораторах, стратегиях, Entity Component, Entity Component System, деревьях, State Machine, частично о хранении хуков в React.
Возможно многих удивит, что в основе большинства подходов повторного использования кода лежат стандартные структуры данных – массив, список, словарь, дерево, граф.
Кляксы (Blob) - это гладкие, аморфные, желеобразные формы, обычно причудливые и забавные. Их можно использовать в качестве элементов иллюстраций и фоновых эффектов в сети.
Итак, как же они устроены? Разумеется, можно открыть какой-то графический редактор и сделайте их, верно? Конечно, это круто. Но мы пишем здесь о CSS финтах, и было бы гораздо интереснее посмотреть на возможности, которые нам дают CSS и SVG - двух наших любимых ингредиентов!
У нас есть несколько способов сделать кляксы. Давай проверим их.
Подборка свежих уроков, видео и пакетов по фреймворку Laravel.
Опрос на telegram-канале Cross Join "Можно ли наследовать класс Пингвин от класса Птица?" удивил. Большая часть людей ответили вполне определённо "да" или "нет" (результаты опроса приложены в конце статьи). Не ожидал такого расклада, поэтому решил написать короткую заметку.
На самом деле, если вам зададут такой вопрос на собеседовании, знайте: тут есть подвох. Даже два.
За эти годы мне посчастливилось работать над некоторыми крупномасштабными проектами, написанными на React. Сегодня я соберу важные вещи, которые нужно учитывать при создании нового проекта или расширении функциональности любого крупномасштабного приложения. Мы начнём с самых основ, а затем пойдём глубже. Так что пристегнитесь!
Сегодня я собираюсь обсудить абсолютно новую для многих пользователей (особенно для питонистов) идею: интеграцию тестов в ваше приложение.
Итак, давайте начнем.
Прошлый год не считается, поэтому начнем все заново:)
Мы анонсируем проведение девятого RamblerFront& Meetup 18-го марта в 19:00. В этом году он пройдет онлайн, но обещает быть столь же интересным, как и предыдущие.
Обязательно регистрируйтесь заранее по ссылке.
Взаимодействовать с API никогда не было просто. Но использовали ли вы когда-нибудь React для отправки формы в Google-таблицы? Если нет, то этот туториал для вас.
Сегодня мы поговорим о том, как отправлять данные формы из React в Google-таблицы, так же как вы отправляете данные с помощью REST API.
Всем привет. Сегодня я расскажу, как мой пулл-реквест замерджили в Angular. Вы узнаете про контрибьют в open source проект такого масштаба и как там проходит код ревью. Всем заинтересованным, добро пожаловать под кат.
Не часто приходится замечать решения предложенные на платформе Tilda, а зря. Почему так? Что такое вообще Tilda и для кого она?
С момента появления интернета веб-разработка прошла очень длинный путь. Это было удивительное путешествие от модемов до оптоволоконных схем. С ростом скорости передачи данных пользователи стали нетерпеливы. Люди ожидают, что их повседневные задачи будут решены здесь и сейчас. Это привело к необходимости создавать сайты, которые работают быстро и без задержек.
Но есть большая проблема, которую мы, как разработчики, должны как-то решать: мы не можем контролировать конфигурацию устройств, с которых пользователи обращаются к нашим сайтам. Это могут быть как мощные, так и слабые машины, с быстрым или медленным подключением к интернету. Поэтому мы должны как можно лучше оптимизировать свои сайты, чтобы они удовлетворяли требованиям любых пользователей.
Веб-разработчики выработали несколько принципов создания сайтов, которые быстро работают даже на самых слабых устройствах. Здесь описаны некоторые из этих принципов. Подчеркну, что они размещены в произвольном порядке.
И последнее: чтобы сохранять баланс между оптимизацией и своевременной поставкой функционала, всегда делитесь и переиспользуйте свой код, точнее — компоненты. Это можно делать с любым репозиторием безо всякой специальной подготовки, достаточно лишь воспользоваться инструментом вроде Bit (Github).
Пару недель назад Django 3.2 выпустил свой первый альфа-релиз, а финальный релиз выйдет в апреле. Он содержит микс новых возможностей, о которых вы можете прочитать в примечаниях к релизу. Эта статья посвящена изменениям в тестировании, некоторые из которых можно получить на более ранних версиях Django с пакетами backport.
