В первой части я уделил внимание только общей концепции: редюсеры, компоненты и экшны чаще меняются одновременно, а не по отдельности, поэтому и группировать и их целесообразнее по модулям, а не по отдельным папкам actions, components, reducers. Также к модулям были предъявлены требования:

1. быть независимыми друг от друга
2. взаимодействовать с приложением через API ядра

В этой части я расскажу о структуре ядра, подходящей для разработки data-driven систем.

Большинство разработчиков начинает знакомство с Redux с Todo List Project. Это приложение имеет следующую структуру:

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

На первый взгляд такая организация кода кажется логичной, ведь она напоминает стандартные соглашения многих backend MVC-фреймворков:

app/
  controllers/
  models/
  views/

На самом деле, это неудачный выбор как для MVC, так и для React+Redux приложений по следующим причинам:

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

Не удивительно, что многие авторы(раз, два, три) советуют структурировать приложение по «функциональности» (by feature).

Сразу скажу, что я не любитель Angular1, angular-way и иже с ними, потому как ребята из Angular таких делов наворотили, что иногда диву даешься. Тем не менее, их новое детище выглядит многообещающе. Да, Америку не открыли, но создали нечто, способное конкурировать с популярными современными фреймворками (React + Redux, Aurelia, и т.д.).

Есть и плюсы, и минусы, о которых уже написаны статьи и даже книги, но суть поста в другом.

RC5 вышел всего неделю назад и «порадовал» разработчиков многими изменениями, которые, возможно, и помогают в работе и упрощают жизнь, но заставят серьёзно попотеть над переписыванием уже написанного кода.

2015 год был значимым годом для Интернета вещей. Мы увидели огромный прогресс в размере и возможностях устройств, большие игроки, такие как Microsoft и Samsung, в буквальном смысле продвигаются в космос и всё IoT сообщество начинает ещё больше разрастаться. В течение двух последних лет здесь, на SitePoint, для меня стало чем-то в роде традиции делать обзор года в ракурсах IoT и JavaScript (см. JavaScript выходит за пределы Web и JavaScript выходит за пределы Web в 2014). Хотя изначальная популярность и ажиотаж вокруг JavaScript, как языка для IoT, похоже немного поутихли за 2015 год, JavaScript всё ещё продолжает позиционироваться как довольно-таки сильный способ для задействования магии на большем числе IoT платформ, чем это себе представляют люди.

В этом обзоре мы рассмотрим некоторые значимые продвижения в IoT, которые раскрывают новые возможности для JavaScript разработчиков и будущий потенциал JavaScript за пределами Web.