ReactJS *

Когда все начинают знакомство с React или Vue, как с двумя самыми популярными фреймворками для frontend, конечно-же все используем магические команды npm install, npm build. И только после этого папочку 'public' Мы деплоим «куда надо».

Но есть и другой (я бы назвал его извращенный) не стандартный способ, о котором многие начинающие фронтэнд разработчики даже не знают, так как они «выросли» на npm install/build.

А что, если не нужно проводить сборку, а просто вставить js код в html?

Подождите плевать мне в лицо и бросать камни с надписью 'I love node'… Мы конечно знаем, что без сборки Мы потеряем юнит тесты, скорость, да и как быть с импортом компонентов, и иерархией файлов, да и вообще спагетти код какой-то получится…

Так для чего Вам (и Нам) это и как это работает ?

На днях к нам прилетел заказ от «бизнеса» по добавлению функционала в их BPM/ERP систему, которая по-сути является сильно модифицированным Redmine. Всё это чудо делалось довольно давно и крутится на VPS сервере с кучей helper'ов микросервисов для считывания данных производства, станков и тп. Трогать ОС нельзя…

Чем React Native отличается от Flutter, за исключением того, что речь идёт о разных фреймворках, в основу которых положены разные технологии? На что ориентироваться тому, кто не знаком с этими инструментами для разработки кросс-платформенных приложений, но хочет выбрать один из них для своего очередного проекта?



Автор статьи, перевод которой мы публикуем, говорит, что в последнее время ему попадалось множество сравнений React Native и Flutter. Во всех этих сравнениях речь шла о таких вещах, которые, на самом деле, особого значения не имеют. Например — о языках, используемых для разработки проектов, или об инструментах командной строки. Здесь будет сделано сравнение React Native и Flutter с точки зрения реального положения дел, с точки зрения того, что имеет значение для настоящих проектов. Это сравнение призвано снабдить всех желающих сведениями, которые помогут им выбрать именно то, что им нужно.

Наткнувшись недавно на статью о react-admin, я решил попробовать что это за зверь. Было интересно прикрутить это к джанге, благо там есть dataprovider для rest framework.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Data Visualization Libraries for React Developers in 2019» автора Veronika Rovnik.

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

Вы когда-нибудь сталкивались с необходимостью улучшить своё приложение аналитическими и визуальными функциями и получить представление о данных?

26 ноября в петербургском офисе Одноклассников состоялся ок.tech: Frontend Meetup #2.
Вместе с коллегами из Одноклассников, ВКонтакте и Hazelcast поговорили про новый фронтенд OK.RU, сделанный на связке React + Graal, обсудили может ли “Lifting State Up” – один из двенадцати ключевых концепций в официальной документации React, приводить к плохой производительности, а также узнали несколько историй про баги и технические решения, которые были предприняты, чтобы с ними справиться.

Заходите под кат если хотите увидеть видеозаписи докладов.

Всем привет, меня зовут Геворг. Я Head of Mobile в Profi.ru. Хочу поделиться с вами историей нашего эксперимента с React Native. Расскажу, как мы оценивали плюсы и минусы разработки на React Native — в теории и на практике. Статья будет полезна тем, кто интересуется кросс-платформенной мобильной разработкой, но пока не решил, идти в эту сторону или нет.

Максимальное ускорение

Всё началось с того, что мы решили ускорить разработку в 10 раз на уровне компании. Поставили невыполнимую цель, чтобы выйти за привычный горизонт событий и попробовать новое. Все команды разработки Profi.ru взялись за эксперименты. На тот момент в компании было 13 нативных мобильных разработчиков, включая меня и двух тимлидов. Моя команда работала над двумя мобильными приложениями. В первом клиенты ищут специалистов, во втором — специалисты клиентов. Для меня этот период был непонятным и эмоционально напряжённым. По моим ощущениям, мы и так много делали, чтобы всё работало быстро.

Использовали общую архитектуру на всём проекте и следили за чистотой кода. Использовали генераторы, которые создают все файлы модулей. Всю бизнес-логику старались выносить на backend. Настроили CI/CD, а приложения покрыли E2E-тестами. За счёт всего этого стабильно релизили некоторые приложения раз в неделю. Я понятия не имел, как ускорить разработку даже в два раза. Куда уж в 10. Поэтому мы определили, что для нас важно.

Если вы делаете Ctrl+C каждый раз при создании нового компонента в реакте, то эта статья точно для вас!

У реакта нет своего CLI, и понятно почему. Не существует определенных правил, как именно должна выглядеть структура компонента, есть только общие рекомендации в документации. Все разработчики используют структуру, которая прижилась в их команде. А иногда и вовсе приходится поддерживать проекты в разных стилях.

Если нужно на коленке получить быстро админку, где фронтендом будет react-admin, а бэкендом Flask-RESTful api, то ниже минимальный код в несколько десятков строк, чтобы это реализовать.

Привет, Хабр! Представляю вашем вниманию перевод статьи «How to Build and Deploy a Full-Stack React-App» автора Frank Zickert.

Компоненты инфраструктуры позволяют легко создавать, запускать и развертывать полноценное React-приложение. С этими React-компонентами вы можете сосредоточиться на написании бизнес-логики вашего приложения. Вам не нужно беспокоиться о его конфигурации.

Хотите стать full-stack разработчиком? Full-stack приложение дополняет интерактивный веб-интерфейс React сервером и базой данных. Но такое приложение требует гораздо больше настроек, чем простое одностраничное приложение.

Фронтенд — одно из самых быстроразвивающихся направлений разработки, вспомните разработку интерфейсов 3-х годичной давности и сравните её с тем, что происходит сейчас и сразу станет понятно — изменилось очень многое, если не совершенно все. С молниеносной скоростью устаревают подходы, считавшиеся передовыми, новый библиотеки становятся популярными буквально в считанные дни.

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

Под катом ответы на многие интересующие вас вопросы.

Зарегистрироваться на мероприятие

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

TL;DR. В большинстве категорий теперь выделяются явные лидеры — несколько лет назад такого не было. Это помогает накоплению знаний. Поэтому Навыки владения инструментами в среднем становятся глубже у разработчиков всех уровней.

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

Как всегда, очень интересно посмотреть на изменения инструментов фронтенда за последние 12 месяцев и как меняются мнения разработчиков в отрасли. Эти результаты (надеюсь) помогут получить представление о текущих тенденциях и уровне освоения инструментов, а также об изменениях во времени, сравнив с цифрами из предыдущих опросов.

Результаты

Итак, к делу! Возьмите чай/кофе/напиток на свой выбор и посмотрим на результаты…

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

Написать работающий сетевой чат без бэкенда практически невозможно, он обязательно должен быть в том или ином виде. Мы будем использовать Chatix и его JavaScript SDK. Chatix и SDK будут заниматься хранением сообщений и сетевыми задачами, а мы займемся фронтендом.

Готовый код проекта доступен на GitHub
Demo

Для создания интерфейсов React рекомендует использовать композицию и библиотеки по управлению состоянием (state management libraries) для построения иерархий компонентов. Однако при сложных паттернах композиции появляются проблемы:

1. Нужно излишне структурировать дочерние элементы
2. Или передавать их в качестве пропсов, что усложняет читабельность, семантичность и структуру кода

Для большинства разработчиков проблема может быть неочевидна, и они перекидывают ее на уровень управления состоянием. Это обсуждается и в документации React:

Сегодня широкое распространение имеют следующие подходы для описания взаимодействия браузера и сервера, такие как OpenApi & GraphQL.

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

26 ноября в петербургском офисе Одноклассников пройдёт ок.tech: Frontend Meetup #2.
Вместе с коллегами из Одноклассников, ВКонтакте и Hazelcast поговорим про новый фронтенд OK.RU, сделанный на связке React + Graal, обсудим может ли “Lifting State Up” – один из двенадцати ключевых концепций в официальной документации React, приводить к плохой производительности, а также узнаем несколько историй про баги и технические решения, которые были предприняты, чтобы с ними справиться.

→ Зарегистрироваться на ок.tech Frontend Meetup #2

Под катом тезисы выступлений и расписание.

Эта статья — попытка свести воедино имеющиеся на текущий момент средства и выяснить, возможно ли создавать production ready приложения на React без предварительной компиляции сборщиками типа Webpack, или по крайней мере свести такую компиляцию к минимуму.

Все описанное носит очень экспериментальный характер и я осознанно местами срезаю углы. Я ни в коем случае не рекомендую делать что-то такое на реальном продакшене.

Возможность использовать ECMAScript modules (<script type="module"/> с импортами вида import Foo from './foo'; и import('./Foo')) прямо в браузере давно не новость, это хорошо поддерживаемы функционал: https://caniuse.com/#feat=es6-module.

Но в реальности мы импортируем не только свои модули, но и библиотеки. Есть отличная статья на эту тему: https://salomvary.com/es6-modules-in-browsers.html. И другая не менее хорошая статья достойная упоминания https://github.com/stken2050/esm-bundlerless.

Среди прочих важных вещей из этих статей, эти пункты наиболее важны для создания React приложения:

• Поддержка package specifier imports (или import maps): когда мы пишем import React from 'react' на самом деле мы должны импортировать что-то подобное https://cdn.com/react/react.production.js
• Поддержка UMD: React до сих пор распространяется как UMD и на данный момент авторы все еще не пришли к согласию как распространять библиотеку в виде модуля
• JSX
• Импорт CSS

Давайте пройдем по всем пунктам по очереди.

10 октября мы провели JavaScript Meetup SuperJob. Рассказываем, что обсуждали участники, делимся видео и презентациями.

Есть много разных библиотек для реализации слайдера со всеми возможными эффектами. Для React одни из лучших это: ReactSlick и Swiper. Но когда для моего проекта потребовался горизонтальный sticky-эффект, то ничего подходящего не нашлось.

В этой статье мы попробуем поэтапно создать такой слайдер, возможно он вам тоже понадобится!

В данной статье я бы хотел рассказать о разрабатываемой мной системе управления контентом Zoia, написанной на Javascript. Это мой side-project, не связанный с основной работой, который я разрабатываю и развиваю в свободное время. Есть мнение, что каждый веб-разработчик должен рано или поздно написать свою собственную CMS, а кто-то даже и не одну :-)

TL;DR: demo.zoiajs.org, панель администратора (логин: admin, пароль: password), Github, лицензия MIT