Comments 41
С почином! Только, пожалуйста, спрячьте под Хабракат после первой картинки, а то неаккуратно получилось.
largescalejs.ru — чисто убить время на чтение. полезной информации 0, только вода. Ибо не рассмотрены реальные проблемы, не показали реальных ситуаций. На словах и без примеров — всегда хорошо, на деле будет ахтунг (мне кажется вы прямо таки от туда и взяли свою идею с модулями, только правда вы сильно упростили подход, тем самым усложным поддержку дальнейшую)
Для загрузки моделй надо не забыть упомянуть requirejs.org
Модуль профиля Profile.js
Я предпочитаю никогда не давать мозможность модулю общаться с сервером на прямую ибо лучше общаться с сервером через единое место.
P.S.
начинающим я советую идти поучить backbone ибо дает очень ясное понимание базовых вещей. так как сам чрезвычайно прост, после нег оможно посмотреть ангулар или нокаут, а уже потом фантазировать на тему своих модулей если таковая потребность будет
Для загрузки моделй надо не забыть упомянуть requirejs.org
Модуль профиля Profile.js
Я предпочитаю никогда не давать мозможность модулю общаться с сервером на прямую ибо лучше общаться с сервером через единое место.
P.S.
начинающим я советую идти поучить backbone ибо дает очень ясное понимание базовых вещей. так как сам чрезвычайно прост, после нег оможно посмотреть ангулар или нокаут, а уже потом фантазировать на тему своих модулей если таковая потребность будет
Про общение с сервером из самого модуля — я подсмотрел в одном из докладов от Яндекса. Основной мыслью в докладе было то, что модуль должен быть «вещью в себе». Сам себя рендерить и сам себе тянуть данные.
Backbone — это ближе к MVC разделению. Для тех проектов что я сейчас делаю — это излишнее усложнение.
Подход из статьи помог мне лучше структурировать код, вот и решил поделиться с другими :)
Backbone — это ближе к MVC разделению. Для тех проектов что я сейчас делаю — это излишнее усложнение.
Подход из статьи помог мне лучше структурировать код, вот и решил поделиться с другими :)
Про общение с сервером из самого модуля — я подсмотрел в одном из докладов от Яндекса. Основной мыслью в докладе было то, что модуль должен быть «вещью в себе». Сам себя рендерить и сам себе тянуть данные.
Это спорно ибо это принесет гигантский оверхед модуль. где он должен будет хендлить ошибки, обрабатывать запросы и прочие ужасные вещи. Наверное если вы это слышали в идеологии БЭМ то там надо договаривать все до конца, БЭМ предполагает разбиение на модули. которые независимы ибо эти модули у них юзаются в десятках проектов. А вот для конретных приложений типо яндекс карт (имнно работа с самими картами), оформлять каждый модуль как полностю зкарытую коробочку — вредно ибо там должно быть динство. В общем то они сами признали что текущий БЭМ плох для этого и переписали полностю ядро сделав другие подходы.
Это спорно ибо это принесет гигантский оверхед модуль. где он должен будет хендлить ошибки, обрабатывать запросы и прочие ужасные вещи. Наверное если вы это слышали в идеологии БЭМ то там надо договаривать все до конца, БЭМ предполагает разбиение на модули. которые независимы ибо эти модули у них юзаются в десятках проектов. А вот для конретных приложений типо яндекс карт (имнно работа с самими картами), оформлять каждый модуль как полностю зкарытую коробочку — вредно ибо там должно быть динство. В общем то они сами признали что текущий БЭМ плох для этого и переписали полностю ядро сделав другие подходы.
Нет про БЭМ я ни слова не говорил.
Обработка запросов необходимых для модуля — происходит внутри самого модуля. Если есть ошибки — модуль генерирует событие «Я сломался» (условно) — которое отлавливается глобальным модулем. Глобальный модуль уже решает что делать. Например можно переинициализировать отвалившийся модуль
Обработка запросов необходимых для модуля — происходит внутри самого модуля. Если есть ошибки — модуль генерирует событие «Я сломался» (условно) — которое отлавливается глобальным модулем. Глобальный модуль уже решает что делать. Например можно переинициализировать отвалившийся модуль
Это вы цитируете largescalejs.ru в реале все сложнее немного.
БЭМ — а в яндексе не он? Вы же прояндекс как бы
БЭМ — а в яндексе не он? Вы же прояндекс как бы
Ну у Яндекс не только о БЭМ'е говорит)) Конкретно в том докладе, которым я вдохновлялся — про БЭМ не было ни слова.
В реале на больших проектах я больше чем уверен, что все будет сложнее. Приведенный выше способ я опробовал на двух небольших проектах, и он себя оправдал. На что то большее конечно лучше смотреть в сторону MV* фреймворков :)
В реале на больших проектах я больше чем уверен, что все будет сложнее. Приведенный выше способ я опробовал на двух небольших проектах, и он себя оправдал. На что то большее конечно лучше смотреть в сторону MV* фреймворков :)
К слову, полностью самостоятельные модули, которые могут использоваться в десятке различных проектов — это уже компонента
Если уж зашла речь про модули и Backbone — то лучше сразу вслед за Backbone смотреть Bacbone.Marionette — это надстройка над Backbone, которая дает в том числе модульность. Т.е. то, о чем написано в статье, только из коробки и с кучей прочих плюшек.
Modernizr может тоже что и yepnope modernizr.com/docs/#load плюс фичи самого modernizr
И все же у вас появляются глобальные переменные, которые засоряют пространство имен. Лучше всего делать модули через Module Pattern и Mixin Pattern. Размещать это все в одном глобальном объекте, например App, и с помощью Facade Pattern сделать хороший доступ к нужным функциям :)
Тоже отличный подход. В largescalejs.ru этот объект называется песочница, как я понял. Но в конце книги есть сноска, о том что добавление песочницы вносит усложнение в код. В моем случае требовался максимально простой способ организации кода.
Но следующем проекте надо попробовать все в глобальный объект собрать :)
Но следующем проекте надо попробовать все в глобальный объект собрать :)
Пожалуйста, не могли бы Вы дать литературу к прочтению на эту тему и, по возможности вкратце рассказать об английских названиях в Вашем комментарии?
Спасибо )
Спасибо )
Литературы на такие вещи нету, только с опытом придет, что и куда лучше располагать.
Английские названия — это паттерны проектирования :)
Очень хорошая книга, рекомендую к прочтению — Клац
Module Pattern — это паттерн, с помощью которого можно реализовать модульную структуру на JavaScript с инкапсуляцией и девушками :)
Mixin Pattern — это паттерн, следуя которому, можно легко расширять существующий функционал модуля без «влезания» в сам модуль.
Facade Pattern — это чисто абстрактивный паттерн, который абстрагирует вашу систему и модули на более высокий уровень, предоставляя очень гибкое и удобное API к вашей системе.
Английские названия — это паттерны проектирования :)
Очень хорошая книга, рекомендую к прочтению — Клац
Module Pattern — это паттерн, с помощью которого можно реализовать модульную структуру на JavaScript с инкапсуляцией и девушками :)
Mixin Pattern — это паттерн, следуя которому, можно легко расширять существующий функционал модуля без «влезания» в сам модуль.
Facade Pattern — это чисто абстрактивный паттерн, который абстрагирует вашу систему и модули на более высокий уровень, предоставляя очень гибкое и удобное API к вашей системе.
Stoyan Stefanov — Javascript Patterns.
Подробно и понятно описаны основные паттерны JS.
Вроде бы есть издание на русском.
Подробно и понятно описаны основные паттерны JS.
Вроде бы есть издание на русском.
Если вы в поиске github'a наберете «javascript design patterns», то найдете пару-тройку неплохих репозиториев на эту тему.
Никто не мешает все модули обернуть в 1 пространство. Где каждый модуль будет свойством глобального объекта
А ещё можно сразу начать писать на es6 modules. И не придумывать велосипед.
Хотя тяга к структурированному коду это хорошо, плюсик вам за это (ну и за картинку — порадовали :) )
Хотя тяга к структурированному коду это хорошо, плюсик вам за это (ну и за картинку — порадовали :) )
Верно, уже давно можно начать пользоваться traceur, ведь кроме модулей в es6 других очень много плюшек. Так что, кто не хочет стоять на одном месте — пора переходить.
Да, на es6 можно уже смело писать. Правда сам traceur не использую — по разным причинам, и на первом месте потому, что он генерит плохой код на выходе.
К сожалению под «браузер» ничего другого толкового нет (насколько мне известно). Но скажу, что если не использовать фичи скрытые за флагами, как `let ` например, то очень он с остальным хорошо справляется. Хотя признаюсь, генераторы ещё не использую, как то страшновата мне их «стэйт-машина» в плане производительности — никак не находится время поближе взглянуть на реализацию и тесты.
Крайне рекомендую посмотреть github.com/ai/evil-blocks
Добавьте в 'use strict' и внутренние методы, которые присваиваются свойствам возвращаемого в public модуля перестанут работать.
Весь этот подход называется шаблон проектирования «модуль». Знаете как применить модуль с использованием 'use strict'?
Весь этот подход называется шаблон проектирования «модуль». Знаете как применить модуль с использованием 'use strict'?
Не совсем понял, что вы имели в виду.
Специально после работы попробовал сломать модуль, используя 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?
Мне кажется, что в слове «Глобаный» фразы «Глобаный модуль App.js» опечатка, Вот только не могу понять, какая — «ль» пропущено, или «рё» заменено? Часто в работе хочется упомянуть вторую версию, но тут вроде бы код аккуратно выглядит.
Sign up to leave a comment.
Организация js кода для джуниоров