ExtJS 3 Code Architecture: лучший способ организовать файлы классов и загрузить их динамически

Question

Я модернизирую устаревшее веб-приложение с его интерфейсом на основе ExtJS 3.x.

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

Чтобы сохранить код и модернизировать его, я хочу постепенно refactorize его:

1. с использованием пространств имен
2. взрывающиеся большие файлы: один класс на файл (сетка, магазин, форма ...)
3. организующех файлов классы в хорошей структуры каталогов (приложение/модуль/сетка | магазине | ...)
4. загружать динамически класс файлов, если требуется (возможно, с Ext.Loader.load()?)
5. оптимизируя загрузку с использованием minifier, в качестве усложнения, если возможно (на следующем шаге).

Всей этой проблематики, кажется, изначально решен в ExtJS 4, с загрузчиком класса, его система зависимостей (require), его Application Singleton и ее конвенция папки структуры ...

В ExtJS 3, это кажется более смущенным. Итак:

• Каковы лучшие практики в extjs 3 для организации кода «как» в extjs 4?
• У вас есть четкие примеры, иллюстрирующие эти проблемы?

Answer 1

Ext3 - совершенно другое зверь, чем 4. Организация кода действительно зависит от разработчика. Я лично избегал бы динамической загрузки в пользу минимизации всего приложения. Это то, что ext4 даст вам в производственном приложении. Они действительно предназначены только для динамической загрузки для целей отладки. Я прошел маршрут динамической загрузки/модуля до Ext3, и это было сожаление. Все в порядке с 4, встроенным в систему классов.

1. Если вы используете более позднюю версию 3, имейте пространство имен с Ext.define. Он будет делать Ext.ns для вас внутренне и сделает обновление до 4 проще по пути.

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

3. Если вы хотите обновить до 4 позже, я бы рекомендовал попробовать немного эмулировать структуру, по крайней мере, с помощью магазинов и просмотров. 3 на самом деле не накладывает никакой структуры.

4. Я бы избегал динамической нагрузки с 3. См. Выше.

5. Определенно минимизировать. Мало того, что на проводе будет намного меньше данных, но вы получите огромную экономию, удалив все накладные расходы GET для каждого скрипта. Gzip может помочь немного.