Перейти к основному содержимому

Ext JS — Model, Store и proxy

Идея​

UI-компонент (грид, форма) не хранит данные внутри — он привязан к Store, который управляет коллекцией Model.

Model​

Описание полей и валидации:

Ext.define('App.model.Task', {
  extend: 'Ext.data.Model',
  fields: [
    { name: 'id', type: 'int' },
    { name: 'title', type: 'string' },
    { name: 'status', type: 'string', defaultValue: 'todo' },
  ],
});

Store​

Ext.create('Ext.data.Store', {
  model: 'App.model.Task',
  autoLoad: true,
  proxy: {
    type: 'ajax',
    url: '/api/tasks',
    reader: { type: 'json', rootProperty: 'data' },
    writer: { type: 'json', writeAllFields: true },
  },
});
МетодДействие
load()загрузка с сервера
sync()отправить изменения
rejectChanges()откат правок

Записи отслеживают состояние — новая, изменённая, удалённая.

Proxy​

ТипНазначение
ajaxHTTP JSON
restREST по соглашению
memoryтесты, прототипы
localstorageофлайн-кэш

Reader/Writer преобразуют ответ сервера в записи Model.

Привязка к гриду​

Ext.create('Ext.grid.Panel', {
  store: taskStore,
  columns: [
    { text: 'ID', dataIndex: 'id' },
    { text: 'Заголовок', dataIndex: 'title', flex: 1 },
  ],
});

Изменение в store автоматически обновляет таблицу (MVVM).

Практика с Node API​

Тот же REST "Заметки", что в Первая программа на Node.js: настройте url, rootProperty и поля модели под ваш JSON.

Связанные материалы​

Расширение темы​

Что важно понимать на практике​

Тема Store/Model/proxy в Ext JS редко ограничивается только определением и одним примером. В реальной работе важно понимать контекст: зачем это нужно бизнесу, какие есть ограничения, и как решение ведет себя при росте нагрузки. Полезный ориентир: любой новый термин должен быть привязан к конкретному сценарию, где он приносит измеримую пользу.

Рабочий подход для новичка​

  1. Сначала собрать минимальный рабочий пример.
  2. Затем усложнить его: добавить негативный сценарий и обработку ошибок.
  3. После этого проверить читаемость и поддержку: понятные имена, единый стиль, комментарии только там, где без них трудно.
  4. В конце — зафиксировать выводы и правила, чтобы команда использовала один подход.

Типичные ошибки​

  • Слишком ранняя оптимизация до понимания базового сценария.
  • Смешение нескольких задач в одном большом модуле.
  • Отсутствие критериев качества, из-за чего решение сложно проверить.
  • Копирование кода без объяснения, почему выбран именно этот путь.

Мини-практика​

Возьмите небольшой фрагмент по теме Store/Model/proxy в Ext JS и улучшите его в три шага: сначала сделайте рабочим, затем устойчивым к ошибкам, затем удобным для чтения другим разработчиком. Так формируется инженерное мышление: также "чтобы запускалось", но и "чтобы поддерживалось".

Как проверять качество результата​

  • Понимает ли другой человек решение без устных пояснений.
  • Есть ли пример входных данных и ожидаемый результат.
  • Очевидно ли, где расширять решение дальше.
  • Не нарушен ли единый стиль раздела и терминов.

Если эти пункты выполняются, материал становится полезным также для знакомства с темой, но и для ежедневной практики.

Дополнительный пример​

Контекст -> Решение -> Проверка -> Выводы

Такой шаблон можно применять почти к любой инженерной задаче: он помогает не терять логику и быстрее объяснять решение команде.

Углубление и сценарии применения​

Сценарий 1 базовый​

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

Сценарий 2 командная разработка​

Когда с материалом работает несколько человек, договоритесь о единых соглашениях: структура файлов, правила именования, формат примеров и критерии готовности. Это уменьшает число конфликтов и ускоряет ревью.

Сценарий 3 масштабирование​

При росте проекта полезно заранее определить границы модулей, точки расширения и ответственность между слоями. Даже простая диаграмма зависимостей помогает увидеть узкие места до того, как они станут проблемой в продакшене.

Антипаттерны​

  • Монолитный модуль без разделения ответственности.
  • Отсутствие тестовых примеров и проверяемых критериев результата.
  • Скрытые зависимости, о которых знает только автор.
  • Документация, которая не совпадает с текущей реализацией.

Что добавить в личный конспект​

  1. Короткое определение термина своими словами.
  2. Один рабочий пример с ожидаемым результатом.
  3. Два частых сбоя и способ их предотвращения.
  4. Мини-шпаргалку по проверке качества перед публикацией.

Так материал превращается из "прочитал и забыл" в инструмент, который можно использовать в работе и обучении.

Углубление и сценарии применения​

Сценарий 1 базовый​

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

Сценарий 2 командная разработка​

Когда с материалом работает несколько человек, договоритесь о единых соглашениях: структура файлов, правила именования, формат примеров и критерии готовности. Это уменьшает число конфликтов и ускоряет ревью.

Сценарий 3 масштабирование​

При росте проекта полезно заранее определить границы модулей, точки расширения и ответственность между слоями. Даже простая диаграмма зависимостей помогает увидеть узкие места до того, как они станут проблемой в продакшене.

Антипаттерны​

  • Монолитный модуль без разделения ответственности.
  • Отсутствие тестовых примеров и проверяемых критериев результата.
  • Скрытые зависимости, о которых знает только автор.
  • Документация, которая не совпадает с текущей реализацией.

Что добавить в личный конспект​

  1. Короткое определение термина своими словами.
  2. Один рабочий пример с ожидаемым результатом.
  3. Два частых сбоя и способ их предотвращения.
  4. Мини-шпаргалку по проверке качества перед публикацией.

Так материал превращается из "прочитал и забыл" в инструмент, который можно использовать в работе и обучении.

Термины простыми словами​

  • SLA — согласованный срок реакции и решения по обращению.
  • Инцидент — сбой, который нарушает работу сервиса.
  • Мастер-данные — ключевые справочники, общие для разных процессов.
  • TCO — полная стоимость владения решением за выбранный период.

См также​

Содержание