Javascript-форум - кто что использует для модульности скриптов?

Javascript-форум (https://javascript.ru/forum/)

- Библиотеки/Тулкиты/Фреймворки (https://javascript.ru/forum/library-toolkit-framework/)

- - кто что использует для модульности скриптов? (https://javascript.ru/forum/library-toolkit-framework/18684-kto-chto-ispolzuet-dlya-modulnosti-skriptov.html)

А не так-то что? tenshi пишет про IE, в IE JScript.

trikadin, JScript != Javascript != ECMAScript != ActionScript != CoffeeScript и чо?

Kolyaj, угу, с мозилловыми стейтментами спутал .-.

Цитата:

Сообщение от tenshi

Kolyaj, угу, с мозилловыми стейтментами спутал .-.

а о каких стейтментах речь?

Цитата:

Сообщение от x-yuri

а о каких стейтментах речь?

(function func() {

   alert(typeof func); // это кстати вместо arguments.callee в ECMAScript 5 предлагают использовать

}());
alert(typeof func); // в старых IE здесь будет функция

if (true) {
  function a() {
    alert(1);
  }
} else {
  function a() {
    alert(2);
  }
}
a();

хм, не назвал бы ie 8 старым...

Мой подход. Правда он для интернет приложений более актуален, чем для сайтов.

1) из глобальных переменных нужен только один нейм спейс. Все остальные нейм спейсы и переменные внутри главного. Это однозначно - иначе при расширении могут возникнуть траблы. В лице нечайного изменения сторонним модулем кому нибудь нужной глобальной переменной.

2) Один компонент один класс/обьект. К примеру в одном обьекте можешь разместить информацию о бизнес обьекте, и методы модификации этой информации. Помоему этот паттерн эксперт называется. Я стараюсь им максимально пользоваться. Желательно чтобы разные компоненты были как можно меньше связаны.

3) Если не знаешь будет ли существовать компонент или нет. Используй систему сообщений для реализации слабого связывания. В отличии от прямого вызова, отсутствие компонента не приведёт к ошибке.

4) Если проект действительно сложный и большой, то не надо упаковывать всё в один файл. Лучше упаковать блоки функциональности по отдельности. Ядро отдельно. Админка отдельно , cтраница с товарами отдельно. Это есть смысл сделать хотябы потому что вряд ли все модули потребуются сразу. И грузить их разом накладно по времени. К приеру для админки. Админка + ядро. Для товаров Товары+ ядро и тд.

5) Желательно разбить всё приложение на 3 части пресловутый MVC. Это облегчит сопровождение.
А) слой Present ответственный за интерфейс.
Б) слой ответственный за логику самого приложения
В) Слой ответственный за данные. (мне он нужен редко если
честно, так как я стараюсь групировать данные и методы в бизнес слое) Это свёртыванием слоёв называется, и это нормальная. практика. Так что не надо ля-ля )))

6) Инициализируй все компоненты из которых состоит приложение в одном месте.

7) можно сделать что-то вроде. GetModule ("список модулей",function(){
действия по инициализации компонента. после загрузки модулей.
get Module должен проверять загружались ли требуемые модули уже. и если нет то грузить
});
Помоему во всех загрузчиках эта возможность уже предусмотрена. labJS к примеру.

Цитата:

Сообщение от DjDiablo

1) из глобальных переменных нужен только один нейм спейс. Все остальные нейм спейсы и переменные внутри главного. Это однозначно - иначе при расширении могут возникнуть траблы. В лице нечайного изменения сторонним модулем кому нибудь нужной глобальной переменной.

и толку от этого неймспейса, если он по сути становится новой глобальной областью видимости?

Цитата:

Сообщение от DjDiablo

2) Один компонент один класс/обьект. К примеру в одном обьекте можешь разместить информацию о бизнес обьекте, и методы модификации этой информации. Помоему этот паттерн эксперт называется. Я стараюсь им максимально пользоваться. Желательно чтобы разные компоненты были как можно меньше связаны.

не нашел такого паттерна и похоже, что речь идет о том, что следует стремиться к слабой связанности (coupling) и сильной связности (cohesion). Я бы только добавил, что надо задумываться о необходимости связей, а не избегать их любой ценой. Потому что есть обратная сторона медали: чем меньше связей, тем сложнее код.

Цитата:

Сообщение от DjDiablo

5) Желательно разбить всё приложение на 3 части пресловутый MVC. Это облегчит сопровождение.
А) слой Present ответственный за интерфейс.
Б) слой ответственный за логику самого приложения
В) Слой ответственный за данные. (мне он нужен редко если
честно, так как я стараюсь групировать данные и методы в бизнес слое)

приведи пример приложений, где это нужно

Цитата:

Сообщение от DjDiablo

Это свёртыванием слоёв называется, и это нормальная. практика. Так что не надо ля-ля )))

где об этом можно почитать?

Цитата:

Сообщение от DjDiablo

6) Инициализируй все компоненты из которых состоит приложение в одном месте.

почему мне не достаточно знать, где что инициализируется, почему мне нужно засунуть это в одно место?

Цитата:

и толку от этого неймспейса, если он по сути становится новой глобальной областью видимости?

Он нестановится новой глобальной областью видимости! Если админ подключит к сайту быдло плагин у которого имя переменной совпадает с твоей, то твой код останется работать. Потому что твоя переменная в своём неймспейсе. и вторая причина Ты можешь раскидать код по неймспейсам код, и тем самым упростить работу с ним.

2) 3.1.4 Информационный эксперт (Information Expert)- GRASP

6)

Цитата:

почему мне не достаточно знать, где что инициализируется, почему мне нужно засунуть это в одно место?

допустим функционал каждого модуля инициализируется в $("document").ready(function(){
инициализация компонента.
});

где гарантия того что все твои ready будут вызываться в нужно тебе порядке ? Лично для меня, невовремя включающиеся модули превратились в реальный геморой.
поэтому в модуле initJs который загружается последним. Есть код

$("document").ready(function(){
    wr.icon.init();       //инициализация 1го модуля
    wr.arranger.init();//инициализация 2го модуля
    wr.history.init();   //инициализация 3го модуля
    wr.inteface.init();  //инициализация 4го модуля
});

соответственно в каждом модуле есть свой метод init.

initJs - стал централизованным местом управления инициализацией приложения. Те модули которые в инициализации в определённом порядке не нуждаются, я неотслеживаю. Впрочем есть и противоположенный подход можно перечислить необходимые модули, прямо