Как стать автором
Обновить

Комментарии 41

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

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

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

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

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

Это спорно ибо это принесет гигантский оверхед модуль. где он должен будет хендлить ошибки, обрабатывать запросы и прочие ужасные вещи. Наверное если вы это слышали в идеологии БЭМ то там надо договаривать все до конца, БЭМ предполагает разбиение на модули. которые независимы ибо эти модули у них юзаются в десятках проектов. А вот для конретных приложений типо яндекс карт (имнно работа с самими картами), оформлять каждый модуль как полностю зкарытую коробочку — вредно ибо там должно быть динство. В общем то они сами признали что текущий БЭМ плох для этого и переписали полностю ядро сделав другие подходы.
Нет про БЭМ я ни слова не говорил.
Обработка запросов необходимых для модуля — происходит внутри самого модуля. Если есть ошибки — модуль генерирует событие «Я сломался» (условно) — которое отлавливается глобальным модулем. Глобальный модуль уже решает что делать. Например можно переинициализировать отвалившийся модуль
Это вы цитируете largescalejs.ru в реале все сложнее немного.
БЭМ — а в яндексе не он? Вы же прояндекс как бы
Ну у Яндекс не только о БЭМ'е говорит)) Конкретно в том докладе, которым я вдохновлялся — про БЭМ не было ни слова.
В реале на больших проектах я больше чем уверен, что все будет сложнее. Приведенный выше способ я опробовал на двух небольших проектах, и он себя оправдал. На что то большее конечно лучше смотреть в сторону MV* фреймворков :)
Есть большие проекты со слабой связанностью и с сильной, о подходе лучше принимать решения только после тщательного анализа проекта
К слову, полностью самостоятельные модули, которые могут использоваться в десятке различных проектов — это уже компонента
Если уж зашла речь про модули и Backbone — то лучше сразу вслед за Backbone смотреть Bacbone.Marionette — это надстройка над Backbone, которая дает в том числе модульность. Т.е. то, о чем написано в статье, только из коробки и с кучей прочих плюшек.
Yepnope интегрирован в Modernizr.
Но не всегда на проекте нужен Modernizr, поэтому был предложен вариант использовать его отдельно
И все же у вас появляются глобальные переменные, которые засоряют пространство имен. Лучше всего делать модули через Module Pattern и Mixin Pattern. Размещать это все в одном глобальном объекте, например App, и с помощью Facade Pattern сделать хороший доступ к нужным функциям :)
Тоже отличный подход. В largescalejs.ru этот объект называется песочница, как я понял. Но в конце книги есть сноска, о том что добавление песочницы вносит усложнение в код. В моем случае требовался максимально простой способ организации кода.
Но следующем проекте надо попробовать все в глобальный объект собрать :)
Пожалуйста, не могли бы Вы дать литературу к прочтению на эту тему и, по возможности вкратце рассказать об английских названиях в Вашем комментарии?
Спасибо )
Литературы на такие вещи нету, только с опытом придет, что и куда лучше располагать.

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

Module Pattern — это паттерн, с помощью которого можно реализовать модульную структуру на JavaScript с инкапсуляцией и девушками :)
Mixin Pattern — это паттерн, следуя которому, можно легко расширять существующий функционал модуля без «влезания» в сам модуль.
Facade Pattern — это чисто абстрактивный паттерн, который абстрагирует вашу систему и модули на более высокий уровень, предоставляя очень гибкое и удобное API к вашей системе.
Stoyan Stefanov — Javascript Patterns.
Подробно и понятно описаны основные паттерны JS.
Вроде бы есть издание на русском.
На русском ее лучше не читать. Не буду остро судить, не читал русское издание.
Английское издание само то, выше привел ссылку как раз на это издание.
Про русское издание я упомянул для информации. Сам предпочитаю читать такие книги на языке оригинала.
Отличная книга на books.ru на русском есть, всем читать не задумываясь!
Если вы в поиске github'a наберете «javascript design patterns», то найдете пару-тройку неплохих репозиториев на эту тему.
Никто не мешает все модули обернуть в 1 пространство. Где каждый модуль будет свойством глобального объекта
Я написал абсолютно то же. Или ваш вариант чем-то отличается?
ghaiklor, да, я невнимателен :)
А ещё можно сразу начать писать на es6 modules. И не придумывать велосипед.
Хотя тяга к структурированному коду это хорошо, плюсик вам за это (ну и за картинку — порадовали :) )
Верно, уже давно можно начать пользоваться traceur, ведь кроме модулей в es6 других очень много плюшек. Так что, кто не хочет стоять на одном месте — пора переходить.
Да, на es6 можно уже смело писать. Правда сам traceur не использую — по разным причинам, и на первом месте потому, что он генерит плохой код на выходе.
К сожалению под «браузер» ничего другого толкового нет (насколько мне известно). Но скажу, что если не использовать фичи скрытые за флагами, как `let ` например, то очень он с остальным хорошо справляется. Хотя признаюсь, генераторы ещё не использую, как то страшновата мне их «стэйт-машина» в плане производительности — никак не находится время поближе взглянуть на реализацию и тесты.
TypeScript, например. Правда там нету let, зато есть многие другие фичи из es6
Добавьте в 'use strict' и внутренние методы, которые присваиваются свойствам возвращаемого в public модуля перестанут работать.

Весь этот подход называется шаблон проектирования «модуль». Знаете как применить модуль с использованием 'use strict'?
Не совсем понял, что вы имели в виду.
Специально после работы попробовал сломать модуль, используя 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();

Продолжает работать.
Можете пояснить ваш комментарий подробнее?
Нашел косяк в коде, все работает! Спасибо за пост, пока готовил подробный ответ с проблемой нашел ошибку в своем коде :)
Автор, Portfolio не вернет объект, поправь самовызов в коде, чтобы в заблуждение не вводить
Какая грубая ошибка. Спасибо что заметили :)
Исправил код
а может, лучше commonJS+browserify/AMD+requireJS?
Лучше, но для тех, кто только начинает заботиться о структурировании кода — подход из статьи проще воспринять, чем сразу кидаться на AMD или еще что либо. По крайней мере мне было проще начинать именно с того что в статье, хотя я на тот момент был знаком с Require js.
Мне кажется, что в слове «Глобаный» фразы «Глобаный модуль App.js» опечатка, Вот только не могу понять, какая — «ль» пропущено, или «рё» заменено? Часто в работе хочется упомянуть вторую версию, но тут вроде бы код аккуратно выглядит.
Спасибо что заметили, но лучше о таких вещах в личку сообщать
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории