Глобальная область видимости (aka namespace в TypeScript) — уже давно не круто. Можно долго перечислять преимущества модулей (ES6 модулей, в частности), но лично для меня решающим стала возможность использовать SystemJS для динамической загрузки исходников и Rollup, для сборки бандла.

Однако, первое, с чем пришлось столкнуться при внедрении ES6-модулей- безумное количество import выражений, с безумным количеством точек внутри:

import { FieldGroup } from "../../../Common/Components/FieldGroup/FieldGroup";

В своей статье я хочу поделиться с вами опытом использования нового Angular как основы для наших enterprise приложений. Речи о том, что новый Angular лучше, чем React, Vue или какая-то другая популярная сейчас библиотека, в статье не пойдет, хотя, конечно, я буду сравнивать его с конкурентами. Все решения имеют свои плюсы и минусы, и то, что хорошо подошло одному проекту, может устроить сущий ад в другом. Итак, прежде чем объяснить, чем нас зацепил новый Аngular, расскажу немного о том, что мы уже используем в разработке.

Наш основной проект имеет долгий путь развития и построен на уже устаревших технологиях — Marionette + Backbone + Coffescript. Пару лет назад мы поняли, что развивать проект в таком стеке стало довольно тяжело, и начали изучать альтернативы в экосистеме фронтенда и думать, как же нам мигрировать туда нашего «зверя».

Какие горизонты открывает React? Single Page Application (и веб-приложения, и десктопные приложения на Electron) — это цветочки. Очень заманчиво выглядит разработка мобильных приложений на React Native. Лозунг "learn once, write anywhere" стоит того, чтобы приложить некоторые усилия. Go!

Всем привет! Хочу поделиться своим переводом статьи React is Slow, React is Fast: Optimizing React Apps in Practice автора François Zaninotto. Надеюсь, это кому-то будет полезным.

Краткое содержание:

1. Измерение производительности React
2. Почему ты обновился?
3. Оптимизация через разбиение на компоненты
4. shouldComponentUpdate
5. Recompose
6. Redux
7. Reselect
8. Остерегайтесь объектных литералов в JSX
9. Заключение

React может быть медленным. Я хочу сказать, что любое React приложение среднего размера может оказаться медленным. Но прежде, чем искать ему замену, вы должны знать, что и любое среднее приложение на Angular или Ember может также оказаться медленным.

Хорошая новость в том, что если вы действительно заботитесь о производительности, то сделать React приложение очень быстрым довольно легко. Об этом — далее в статье.

Как говорится, в редакцию пришло письмо: "не могли бы вы подробно разъяснить..." Отвечаю публично, кому оно надо, а применение можно пощупать тут.

actions/
  todos.js
components/
  todos/
    TodoItem.js
    ...
constants/
  actionTypes.js
reducers/
  todos.js
index.js
rootReducer.js

app/
  controllers/
  models/
  views/

1. С ростом приложения следить за взаимосвязью между компонентами, экшнами и редюсерами становится крайне сложно
2. При изменении экшна или компонента с большой вероятностью потребуется внести изменения и в редюсер. Если количество файлов велико, скролить IDE вверх/вниз не удобно
3. Такая структура потворствует копипасте в редюсерах

Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

В данной публикации мы рассмотрим, как создать npm пакет React компонентов используя create-react-app.

Недавно я столкнулся с задачей переноса папки с проектом из одного репозитория в другой на github. Звучит примитивно, но если рассмотреть то, что дано и то, что необходимо получить, могут возникнуть некоторые нюансы.

Итак, что дано:

• Есть большой репозиторий, содержащий множество папок. Каждая папка – это отдельный проект.

Что необходимо сделать:

• Одну из папок перенести в отдельный репозиторий с сохранением ее истории коммитов.

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

Я использовал стандартный гитовый filter-branch. За основу я взял следующие статьи:

• Moving Files from one Git Repository to Another, Preserving History
• Splitting a subfolder out into a new repository

В этом посте я хочу немного адаптировать процесс для лучшего восприятия.

Многие руководствуются рекомендациями Presentational and Container Components, но уважаемый автор признаётся в сносках, что концепция разделения спорная, и компоненты можно смешивать. А если это так, то зачем тащить чемодан без ручки? Все компоненты проекта удобнее хранить в одной общей папке. Какие плюсы:

• Простота навигации по файловой системе.
• Уникальные имена компонентов проекта.
• Импорт без боли ('../../../../../..').

Когда проект вырастет, следует дробить его на приватные npm-пакеты, инкапсулируя реализацию. Но не выращивать дерево подпапок внутри папки компонентов — развивать и поддерживать такое ощутимо сложнее. Проверено.

Привет, Хабр, я тут написал онлайн версию замечательной настольной игры "Эволюция: Происхождение видов" и хотел бы поделиться своими заметками насчет архитектуры и технических моментов. Сразу уточню — я не пиарюсь, скорее, мне интересно рассказать про ошибки и фичи, а взамен услышать много нового и хорошего о своих решениях и коде.

Каждый раз начиная писать React приложение, вы так или иначе выберите какой-то вариант:

• копи-паст вашего предыдущего проекта
• какой-то бойлерплейт или даже генератор (типа Yeoman)
• готовый фреймворк не требующий конфигурации
• пишете сами все с нуля

Каждый из способов имеет свои сильные и слабые стороны, как на длинной, так и на короткой дистанции.

Некоторые решения скрывают сложность в начале, позволяя сделать быстрый старт. Это что-то вроде решения под ключ, но в результате такие решения могут оказаться недостаточно гибкими и сложными в подстройке. С другой стороны, в начале все может казаться слегка монструозным и неповоротливым, и чтоб начать нужно немного повозиться, но зато потом преимущества станут очевидными. Всегда есть возможность сделать все с нуля, ровно так, как хочется, но в таком случае Вы будете отвечать за бесчисленные аспекты и Вам потребуются очень глубокие знания во всех участвующих технологиях.

При выполнении очередного госзаказа наша команда столкнулась с проблемой интеграции сайта с ЕСИА. Инструкции по решению этой задачи в сети нет, кроме информации в официальных документах МинКомСвязи (примерно 300 страниц в трех регламентах). Также есть компании, которые оказывают платные услуги по интеграции ЕСИА. Мы реализовали, описали процесс интеграции и решили поделиться с сообществом habrahabr.