ReactJS *

Всем привет! Идеологически Quarkly – это проект, который призван упростить жизнь веб-разработчикам и веб-дизайнерам. В этом посте я коротко расскажу, за счет чего это возможно.

Прежде всего, давайте посмотрим, как выглядит типичный цикл разработки веб-приложения в 2020 году? Есть команда. В этой команде есть дизайнер и разработчик. Первый создает дизайн-спецификацию в Figma. Второй, на основе дизайн-спецификации, создает компоненты, переносит тему. Результат своей работы программист показывает дизайнеру в Storybook. Дизайнер его проверяет и утверждает проект, если всё хорошо. Далее он начинает создавать макеты, а разработчик верстает их при помощи компонентов из спецификации.

Мне 17 лет и я уже несколько месяцев делаю клон мобильного приложения Хабра, назвав его соответствующе, модно, со стилем и пафосной точкой в конце — habra. Получилось реализовать несколько фич, которых пока нет ни в официальном приложении из плей маркета, ни на самом сайте.

Ссылка на web-приложение для самых нетерпеливых — habra.js.org. Всех остальных — прошу под кат.

При работе с TensorFlowJS можно выделить три направления (рисунок 1):

1. использование обученных моделей без модификаций топологий и переобучений

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

3. создание и обучения моделей с нуля.

1. * Создание root application из вашего существующего проекта, добавление в него 3 микро-приложения (vue, react, angular)
2. Общение между микро-приложениями
3. Работа с git (deploy, обновления)

1. Общая часть
2. Зачем это нужно
3. Создание root контейнера (определение см. ниже) из вашего монолита
4. Создаем микро-приложение VUE (vue-app)
5.  Создаем микро-приложение REACT (react-app)
6.  Создаем микро-приложение ANGULAR (angular-app)

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

Это третья часть из серии о тестировании с React. В прошлой части мы рассмотрели базовый формат моков React компонентов.

Еще одна вещь, которую вы можете сделать с помощью моков, - это проверить, правильные ли дочерние элементы были переданы. Вот собственно на это мы сейчас и посмотрим.

В преддверии старта курса «Автоматизация тестирования на JavaScript» продолжаем публиковать перевод серии полезных статей

В первой части этой серии статей мы рассмотрели, почему моки на самом деле полезны.

В этой части я расскажу о базовом формате маков React компонентов.

В статье Как управлять состоянием React приложения без сторонних библиотек, я писал о том как сочетание локального состояния и контекста (React Context) поможет вам упростить управление состоянием при разработке приложения. В этой статье я продолжу эту тему - мы поговорим о методах эффективного использования потребителей контекста (Context Consumer), которые помогут вам избежать ошибок и упростят разработку приложений и/или библиотек.

Рекомендую перед прочтением этой статьи прочитать Как управлять состоянием React приложения без сторонних библиотек. Особенно обратите внимание на рекомендацию о том что не нужно применять контексты для решения всех проблем связанных с передачей состояния. Однако, когда вам все таки понадобиться применять контексты, надеюсь эта статья поможет вам делать это наиболее эффективным образом. Так же помните о том что контексты НЕ обязательно должны быть глобальными, контекст может (и скорее всего, должен) быть частью какой либо ветки в структуре вашего приложения.

Давайте, для начала, создадим файл src/count-context.js и пропишем там наш контекст:

Существует много возможныx вариантов реализации сложных графиков в ваших проектах. Я за несколько лет попробовал все возможные варианты. Сначала это были готовые библиотеки типа AmCharts 4. AmCharts сразу же оказался большим и неповоротливым. После этого были более гибкие и дружелюбные библиотеки, такие как Recharts. Recharts был поначалу очень хорош, но со временем сложные фичи создавались такими костылями, которые даже показывать стыдно, а какие-то фичи и вовсе были невозможны в реализации. Таким образом, я пришел к D3 и решаю на нем любые задачи, связанные с графиками. Иногда это занимает немного больше времени по сравнению с готовыми инструментами. Но остается одно неоспоримое преимущество – мы всегда знаем, что никогда не упремся в рамки и ваш код не захочется отправить в помойку через пару месяцев.

Какая цель этой статьи? Я хочу рассказать вам про крутой инструмент и о том, как его максимально эффективно использовать в связке с React. Мы последовательно разберем универсальный рецепт для построения компонентов любой сложности.

• useMemoCompare
• useAsync
• useRequireAuth
• useRouter
• useAuth
• useEventListener
• useWhyDidYouUpdate
• useDarkMode
• useMedia
• useLocalStorage

Меня зовут Назим Гафаров, я разработчик интерфейсов в Mail.ru Cloud Solutions. На дворе 2020 год, а мы продолжаем обсуждать «нововведения» ES6-синтаксиса и преимущества MobX над Redux. Существует много причин использовать Redux в своем проекте, но так как я не знаю ни одной, расскажу о том, почему мы выбрали MobX.

Что такое Axios?

Всем привет, меня зовут Ростислав, я занимаю должность Front Lead в компании ДомКлик. Хочу поделиться с вами опытом создания Web Core команды и сразу ответить на следующие вопросы:

• Необходима ли такая команда в компании?

После года существования команды Web Core, у всех сложилось понимание, что в больших компаниях это необходимо, а в стартапах — не обязательно.

• Выгодно ли внедрять такую команду?

Безусловно. Изначально было сложно измерить и спрогнозировать выгоду от её создания, все расчеты, P&L были на словах, в цифрах — только примерные предположения. Спустя год мы можем посчитать сэкономленное время, профиты, и все расчеты говорят о том, что это было не зря.

• На долгую перспективу ли эта команда?

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

• Чем эта команда занимается?

Основное направление — дизайн система, но по ходу её разработки у нас появилось еще много интересных задач.

• Использование коллекции способствует созданию бандлов приложений маленького размера. Дело в том, что visx разбита на множество пакетов. Поэтому при её использовании в некоем проекте можно взять из неё лишь то, что нужно.
• Коллекция спроектирована так, чтобы не навязывать программистам некие предопределённые схемы работы. Используя visx, разработчик может использовать собственную систему управления состоянием приложения, свою библиотеку анимации или подходящее ему CSS-in-JS-решение. Высока вероятность того, что при создании вашего React-приложения уже приняты решения о том, как в нём выполняются анимации, о том, какой подход используется для работы с темами, о том, как стилизуются элементы. Visx, в этом плане, ничего нового в приложения не добавляет. Библиотека интегрируется со всем тем, что уже есть в проект.
• Это — не коллекция элементов, «заточенная» под создание графиков. Если вы будете пользоваться визуализационными примитивами для создания графиков, то вы, в итоге, создадите собственную библиотеку, решающую эту задачу. Причём, это будет библиотека, оптимизированная под ваши нужды. Она будет находиться под вашим полным контролем.

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

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

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