Организация js кода для джуниоров

[@ZlodeiBaal]

С почином! Только, пожалуйста, спрячьте под Хабракат после первой картинки, а то неаккуратно получилось.

[@Insayt]

Спасибо. Все поправил

[@kirichenko]

[@Seldon]

largescalejs.ru — чисто убить время на чтение. полезной информации 0, только вода. Ибо не рассмотрены реальные проблемы, не показали реальных ситуаций. На словах и без примеров — всегда хорошо, на деле будет ахтунг (мне кажется вы прямо таки от туда и взяли свою идею с модулями, только правда вы сильно упростили подход, тем самым усложным поддержку дальнейшую)

Для загрузки моделй надо не забыть упомянуть requirejs.org

Модуль профиля Profile.js
Я предпочитаю никогда не давать мозможность модулю общаться с сервером на прямую ибо лучше общаться с сервером через единое место.

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

[@Insayt]

Про общение с сервером из самого модуля — я подсмотрел в одном из докладов от Яндекса. Основной мыслью в докладе было то, что модуль должен быть «вещью в себе». Сам себя рендерить и сам себе тянуть данные.

Backbone — это ближе к MVC разделению. Для тех проектов что я сейчас делаю — это излишнее усложнение.
Подход из статьи помог мне лучше структурировать код, вот и решил поделиться с другими :)

[@Seldon]

Про общение с сервером из самого модуля — я подсмотрел в одном из докладов от Яндекса. Основной мыслью в докладе было то, что модуль должен быть «вещью в себе». Сам себя рендерить и сам себе тянуть данные.

Это спорно ибо это принесет гигантский оверхед модуль. где он должен будет хендлить ошибки, обрабатывать запросы и прочие ужасные вещи. Наверное если вы это слышали в идеологии БЭМ то там надо договаривать все до конца, БЭМ предполагает разбиение на модули. которые независимы ибо эти модули у них юзаются в десятках проектов. А вот для конретных приложений типо яндекс карт (имнно работа с самими картами), оформлять каждый модуль как полностю зкарытую коробочку — вредно ибо там должно быть динство. В общем то они сами признали что текущий БЭМ плох для этого и переписали полностю ядро сделав другие подходы.

[@Insayt]

Нет про БЭМ я ни слова не говорил.
Обработка запросов необходимых для модуля — происходит внутри самого модуля. Если есть ошибки — модуль генерирует событие «Я сломался» (условно) — которое отлавливается глобальным модулем. Глобальный модуль уже решает что делать. Например можно переинициализировать отвалившийся модуль

[@Seldon]

Это вы цитируете largescalejs.ru в реале все сложнее немного.
БЭМ — а в яндексе не он? Вы же прояндекс как бы

[@Insayt]

Ну у Яндекс не только о БЭМ'е говорит)) Конкретно в том докладе, которым я вдохновлялся — про БЭМ не было ни слова.
В реале на больших проектах я больше чем уверен, что все будет сложнее. Приведенный выше способ я опробовал на двух небольших проектах, и он себя оправдал. На что то большее конечно лучше смотреть в сторону MV* фреймворков :)

[@Seldon]

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

[@Sild]

К слову, полностью самостоятельные модули, которые могут использоваться в десятке различных проектов — это уже компонента

[@Andrey_Kuprikov]

Если уж зашла речь про модули и Backbone — то лучше сразу вслед за Backbone смотреть Bacbone.Marionette — это надстройка над Backbone, которая дает в том числе модульность. Т.е. то, о чем написано в статье, только из коробки и с кучей прочих плюшек.

[@xGromMx]

Modernizr может тоже что и yepnope modernizr.com/docs/#load плюс фичи самого modernizr

[@Insayt]

Yepnope интегрирован в Modernizr.
Но не всегда на проекте нужен Modernizr, поэтому был предложен вариант использовать его отдельно

[@ghaiklor]

И все же у вас появляются глобальные переменные, которые засоряют пространство имен. Лучше всего делать модули через Module Pattern и Mixin Pattern. Размещать это все в одном глобальном объекте, например App, и с помощью Facade Pattern сделать хороший доступ к нужным функциям :)

[@Insayt]

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

[@Mushtat]

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

[@ghaiklor]

Литературы на такие вещи нету, только с опытом придет, что и куда лучше располагать.

Английские названия — это паттерны проектирования :)
Очень хорошая книга, рекомендую к прочтению — Клац

Module Pattern — это паттерн, с помощью которого можно реализовать модульную структуру на JavaScript с инкапсуляцией и девушками :)
Mixin Pattern — это паттерн, следуя которому, можно легко расширять существующий функционал модуля без «влезания» в сам модуль.
Facade Pattern — это чисто абстрактивный паттерн, который абстрагирует вашу систему и модули на более высокий уровень, предоставляя очень гибкое и удобное API к вашей системе.

[@Ashot]

Stoyan Stefanov — Javascript Patterns.
Подробно и понятно описаны основные паттерны JS.
Вроде бы есть издание на русском.

[@ghaiklor]

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

[@Ashot]

Про русское издание я упомянул для информации. Сам предпочитаю читать такие книги на языке оригинала.

[@AlexPTS]

Отличная книга на books.ru на русском есть, всем читать не задумываясь!

[@aen]

Если вы в поиске github'a наберете «javascript design patterns», то найдете пару-тройку неплохих репозиториев на эту тему.

[@AlexPTS]

Никто не мешает все модули обернуть в 1 пространство. Где каждый модуль будет свойством глобального объекта

[@ghaiklor]

Я написал абсолютно то же. Или ваш вариант чем-то отличается?

[@AlexPTS]

ghaiklor, да, я невнимателен :)

[@termi]

А ещё можно сразу начать писать на es6 modules. И не придумывать велосипед.
Хотя тяга к структурированному коду это хорошо, плюсик вам за это (ну и за картинку — порадовали :) )

[@tenbits]

Верно, уже давно можно начать пользоваться traceur, ведь кроме модулей в es6 других очень много плюшек. Так что, кто не хочет стоять на одном месте — пора переходить.

[@termi]

Да, на es6 можно уже смело писать. Правда сам traceur не использую — по разным причинам, и на первом месте потому, что он генерит плохой код на выходе.

[@tenbits]

К сожалению под «браузер» ничего другого толкового нет (насколько мне известно). Но скажу, что если не использовать фичи скрытые за флагами, как `let ` например, то очень он с остальным хорошо справляется. Хотя признаюсь, генераторы ещё не использую, как то страшновата мне их «стэйт-машина» в плане производительности — никак не находится время поближе взглянуть на реализацию и тесты.

[@termi]

TypeScript, например. Правда там нету let, зато есть многие другие фичи из es6

[@aishek]

Крайне рекомендую посмотреть github.com/ai/evil-blocks

[@AlexPTS]

Добавьте в 'use strict' и внутренние методы, которые присваиваются свойствам возвращаемого в public модуля перестанут работать.

Весь этот подход называется шаблон проектирования «модуль». Знаете как применить модуль с использованием 'use strict'?

[@Insayt]

Не совсем понял, что вы имели в виду.
Специально после работы попробовал сломать модуль, используя use strict — не получилось

var some = (function(){
    "use strict";
    var arr = ['Проверка', 'на', 'вшивость'];
    
    return {
        getFirst: function(){
            alert(arr[0]);
        }
    };
})();

some.getFirst();

Как и

"use strict";

var some = (function(){
    
    var arr = ['Проверка', 'на', 'вшивость'];
    
    return {
        getFirst: function(){
            alert(arr[0]);
        }
    };
})();

some.getFirst();

Продолжает работать.
Можете пояснить ваш комментарий подробнее?

[@AlexPTS]

Нашел косяк в коде, все работает! Спасибо за пост, пока готовил подробный ответ с проблемой нашел ошибку в своем коде :)

[@AlexPTS]

Автор, Portfolio не вернет объект, поправь самовызов в коде, чтобы в заблуждение не вводить

[@Insayt]

Какая грубая ошибка. Спасибо что заметили :)
Исправил код

[@Jabher]

а может, лучше commonJS+browserify/AMD+requireJS?

[@Insayt]

Лучше, но для тех, кто только начинает заботиться о структурировании кода — подход из статьи проще воспринять, чем сразу кидаться на AMD или еще что либо. По крайней мере мне было проще начинать именно с того что в статье, хотя я на тот момент был знаком с Require js.

[@minister35]

Мне кажется, что в слове «Глобаный» фразы «Глобаный модуль App.js» опечатка, Вот только не могу понять, какая — «ль» пропущено, или «рё» заменено? Часто в работе хочется упомянуть вторую версию, но тут вроде бы код аккуратно выглядит.

[@Insayt]

Спасибо что заметили, но лучше о таких вещах в личку сообщать