Undo context save

[amikhaylin]

No description provided.

[github-actions]

Code review by ChatGPT

[github-actions]

Внесенные изменения удаляют вызов try? modelContext.save() внутри модификатора .refreshable. Это может привести к следующим проблемам и требует дополнительного рассмотрения:

1. Отсутствие сохранения данных при обновлении:

   • Если modelContext.save() отвечал за сохранение изменений в контексте перед обновлением, его удаление может привести к потере данных или несохраненным изменениям. Убедитесь, что сохранение данных происходит в другом месте или что это намеренное изменение.

2. Обработка ошибок:

   • Использование try? подавляет ошибки, что может усложнить отладку и выявление проблем при сохранении данных. Рекомендуется использовать более явную обработку ошибок, например, do-catch, чтобы можно было реагировать на возможные сбои сохранения:

     .refreshable {
         do {
             try modelContext.save()
             refresher.refresh.toggle()
         } catch {
             // Обработка ошибки, например, показ пользователю
             print("Ошибка сохранения: \(error)")
         }
     }

3. Консистентность состояния:

   • Убедитесь, что состояние refresher.refresh синхронизировано с состоянием данных. Если сохранение данных критично для обновления интерфейса, отсутствие вызова save() может привести к несоответствию между данными и отображением.

4. Повторяемость кода:

   • В представленном диффе одинаковые изменения применены в нескольких местах (-47, -60, -73). Возможно, стоит рассмотреть возможность вынесения общего кода в отдельный метод или использовать более эффективные подходы для управления обновлениями, чтобы избежать дублирования.

5. Тестирование:

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

Рекомендации:

• Пересмотрите необходимость удаления modelContext.save(). Если сохранение необходимо, восстановите вызов и улучшите обработку ошибок.
• Если сохранение действительно должно происходить в другом месте, убедитесь, что это реализовано корректно и документировано.
• Минимизируйте дублирование кода для повышения читаемости и поддержки.

[github-actions]

Ваши изменения показывают удаление параметра modelContext из методов setDueDate и reconnect. Вот несколько замечаний и рекомендаций:

1. Доступность modelContext в методах:

   • Убедитесь, что modelContext доступен внутри методов setDueDate и reconnect без передачи его как параметра. Если эти методы находятся внутри объекта, который уже имеет доступ к modelContext, это обоснованно. Однако, если modelContext ранее передавался явно, возможно, его использование внутри методов теперь будет нарушено.

2. Инкапсуляция зависимостей:

   • Если modelContext является глобальной зависимостью или передается через окружение (Environment), убедитесь, что это не ухудшает тестируемость и поддерживаемость кода. Иногда явная передача зависимостей облегчает управление ими и делает код более прозрачным.

3. Последствия изменений:

   • Проверьте, что удаление modelContext из вызовов методов не приводит к ошибкам выполнения или некорректной работе логики. Убедитесь, что все места, где вызываются setDueDate и reconnect, корректно работают с новыми сигнатурами методов.

4. Обработка ошибок:

   • Если методы setDueDate и reconnect выполняют операции, требующие modelContext, убедитесь, что они должным образом обрабатывают случаи, когда modelContext недоступен или неправильно настроен.

5. Консистентность кода:

   • Убедитесь, что изменения синхронизированы по всему проекту. Если setDueDate и reconnect используются в других местах, необходимо обновить их вызовы везде, чтобы избежать несоответствий.

6. Документация:

   • Обновите комментарии и документацию методов setDueDate и reconnect, чтобы отразить изменения в их сигнатурах и способах использования.

7. Тестирование:

   • Добавьте или обновите юнит-тесты для методов setDueDate и reconnect, чтобы убедиться, что они работают корректно без передачи modelContext как параметра.

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

[github-actions]

Ваш код в целом выглядит хорошо, однако есть несколько моментов, которые можно улучшить:

1. Изменение точки крепления поповера:

   • Прежнее значение: .point(.bottomTrailing)
   • Новое значение: .point(.top)

   Комментарий: Изменение точки крепления с нижнего правого угла на верхнюю может привести к неожиданному расположению поповера относительно кнопки. Убедитесь, что новое расположение соответствует дизайн-макету и обеспечивает удобство для пользователей. Возможно, стоит протестировать оба варианта на разных устройствах и ориентациях экрана, чтобы проверить, как изменение влияет на пользовательский опыт.

2. Использование фиксированных размеров:

   .frame(width: geometry.size.width * 0.9, height: 220)

   Предложение: Вместо фиксированной высоты 220 рассмотрите возможность использования адаптивных размеров или зависимых от содержимого. Это обеспечит более гибкий интерфейс, особенно на устройствах с разными размерами экранов.

   .frame(width: geometry.size.width * 0.9)

   Или используйте .fixedSize для контента, если это применимо.

3. Использование .constant([]) для tasks:

   tasks: .constant([])

   Комментарий: Передача .constant([]) делает tasks неизменяемым внутри NewTaskView. Если NewTaskView предполагает возможность изменения списка задач, лучше использовать @Binding или другой механизм передачи изменяемого состояния. Это позволит сохранять изменения и обновлять интерфейс динамически.

   @State private var tasks: [Task] = []
   
   // Вызов
   tasks: $tasks

4. Адаптация представления на разных устройствах:

   .presentationCompactAdaptation(.popover)

   Комментарий: Убедитесь, что адаптация .popover подходит для всех целевых устройств, включая iPad и macOS. Возможно, стоит рассмотреть другие варианты адаптации или добавить дополнительные условия для более точного управления поведением поповера в разных контекстах.

5. Доступность и идентификаторы:

   .accessibility(identifier: "AddTaskToInboxButton")

   Предложение: Продолжайте уделять внимание доступности. Помимо идентификаторов, убедитесь, что все элементы имеют соответствующие метки и поддерживают навигацию с помощью голосовых ассистентов и других технологий доступности.

6. Обработка состояния newTaskIsShowing:
   Комментарий: Проверьте, правильно ли управляется состояние newTaskIsShowing. Убедитесь, что поповер корректно отображается и скрывается в зависимости от этого состояния, и что нет возможных случаев, когда состояние может оставаться несинхронизированным с отображением интерфейса.

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

[github-actions]

Изменение кода касается удаления параметра modelContext из метода setDueDate. Вот несколько замечаний и рекомендаций:

1. Проверка зависимости modelContext внутри setDueDate:

   • Если метод setDueDate ранее требовал modelContext для выполнения своих задач, убедитесь, что сейчас он может корректно работать без этого параметра. Возможно, modelContext теперь доступен через инъекцию зависимостей или иным способом внутри самого метода.

2. Согласованность использования modelContext:

   • В текущем фрагменте modelContext всё ещё используется для вставки задачи (modelContext.insert(task)). Убедитесь, что удаление modelContext из setDueDate не нарушает общую логику работы с контекстом модели. Если оба метода должны работать с одним и тем же контекстом, стоит удостовериться, что они используют его согласованно.

3. Обработка ошибок:

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

4. Документация и комментарии:

   • Обновите документацию метода setDueDate, чтобы отразить изменение интерфейса. Если modelContext больше не используется, это должно быть указано для обеспечения понятности кода для других разработчиков.

5. Тестирование:

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

6. Рассмотрите использование @Environment или других подходов для доступа к modelContext:

   • Если modelContext часто используется в разных частях представления, возможно, стоит рассмотреть его внедрение через среду (@Environment) или другие механизмы инъекции зависимостей, что может упростить сигнатуры методов и повысить читаемость кода.

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

[github-actions]

Ваши изменения выглядят стремительными и направлены на упрощение вызовов методов, что может повысить читаемость кода. Однако, есть несколько моментов, которые стоит учесть:

1. Удаление modelContext:

   • Проверка внутренних методов: Убедитесь, что методы reactivate(), setDueDate(dueDate:), nextWeek() и skip() внутри модели Task теперь самостоятельно управляют modelContext. Если раньше контекст передавался извне, необходимо убедиться, что контекст доступен внутри этих методов, возможно, через внедрение зависимостей или другой способ.
   • Обработка ошибок: Если modelContext использовался для сохранения изменений или управления транзакциями, вы должны убедиться, что новые методы правильно обрабатывают возможные ошибки и сохраняют состояние.

2. Повторные вызовы tasks.remove(at: index):

   • Целостность данных: После изменения даты выполнения задачи вы удаляете задачу из текущего списка. Убедитесь, что это поведение соответствует ожидаемому функционалу и не приводит к несоответствиям в отображении данных.
   • Оптимизация поиска индекса: Если операция firstIndex(of:) часто используется, возможно, имеет смысл оптимизировать поиск индекса или хранить задачи в структуре данных, которая обеспечивает более быстрый доступ.

3. Обновление WidgetCenter:

   • Частота обновлений: Вызываете WidgetCenter.shared.reloadAllTimelines() после каждого изменения задачи. Рассмотрите возможность объединения нескольких обновлений в один вызов, если операции происходят часто, чтобы снизить нагрузку и улучшить производительность.
   • Целевые виджеты: Если ваши изменения касаются только определённых виджетов, используйте более специфичные методы обновления вместо reloadAllTimelines(), чтобы снизить расход ресурсов.

4. Управление presentationMode:

   • Асинхронные операции: Убедитесь, что вызовы dismiss() происходят после успешного завершения всех асинхронных операций, связанных с модификацией задачи, чтобы избежать неконсистентного состояния интерфейса.

5. Обработка дат:

   • Использование Calendar: При работе с датами используйте Calendar.current последовательно и убедитесь, что настройки календаря соответствуют требованиям вашего приложения (например, часовой пояс, локализация).
   • Безопасность опционалов: В методе setDueDate(dueDate:) вы передаёте результат Calendar.current.date(byAdding:), который возвращает опционал. Убедитесь, что метод setDueDate корректно обрабатывает nil значения и возможные несоответствия дат.

6. Повторяемость задач (repeation):

   • Правописание: В строке if task.repeation != .none { вероятно опечатка. Правильное написание — repetition.
   • Логика обработки: Убедитесь, что метод skip() корректно обрабатывает логику пропуска повторения задачи и обновляет состояние задачи в соответствии с бизнес-логикой.

Рекомендации:

• Тестирование: После внесения изменений обязательно проведите тщательное тестирование всех сценариев использования задач, особенно касающихся изменения дат и повторений.
• Документация: Обновите документацию методов модели Task, чтобы отразить изменения в их сигнатурах и поведении.
• Код-ревью: Рассмотрите возможность использования инструментов статического анализа и автоматизированного тестирования для выявления потенциальных ошибок и повышения качества кода.

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

[github-actions]

В вашем изменении кода вы удалили строку try? modelContext.save(). Вот несколько замечаний и предложений по улучшению:

1. Сохранение контекста данных:

   • Потеря данных: Удаление modelContext.save() может привести к тому, что изменения в контексте данных не будут сохраняться. Убедитесь, что это намеренное действие и что сохранение обработки происходит в другом месте.
   • Контроль ошибок: Использование try? подавляет возможные ошибки. Рекомендуется обработать возможные исключения, чтобы иметь возможность реагировать на ошибки сохранения. Например:

     do {
         try modelContext.save()
     } catch {
         // Логирование ошибки или показ пользователю
         print("Ошибка сохранения контекста: \(error)")
     }

2. Обновление состояния:

   • Тоггл обновления: Вы используете refresher.refresh.toggle(), что хорошо для обновления состояния. Однако, стоит убедиться, что это не приводит к нежелательным побочным эффектам, таким как бесконечные циклы обновления.
   • Оптимизация обновления: Если возможны множественные вызовы refresh, подумайте о том, чтобы использовать debounce или другой механизм для предотвращения избыточных обновлений.

3. Архитектурные решения:

   • Разделение ответственности: Если сохранение данных не должно происходить внутри refreshable, убедитесь, что это логичное разделение согласно архитектуре вашего приложения (например, MVVM).
   • Тестируемость: Убедитесь, что изменения не усложняют тестирование соответствующих компонентов. Возможно, стоит вынести сохранение контекста в отдельный метод или сервис.

4. Читаемость кода:

   • Комментарии и документация: Если удаление modelContext.save() связано с определённой логикой, имеет смысл добавить комментарий, объясняющий это решение для будущих разработчиков.

5. Использование environmentObject:

   • Передача объектов: Убедитесь, что showInspector корректно передаётся через environmentObject и что все подчинённые представления правильно его используют.

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

[github-actions]

Ваши изменения демонстрируют хорошие усилия по улучшению кода. Однако, есть несколько моментов, на которые стоит обратить внимание:

1. Удаление modelContext из методов disconnectFromParentTask и reactivate:

   • Проверка доступа к modelContext: Убедитесь, что методы disconnectFromParentTask() и reactivate() могут корректно получить доступ к modelContext без передачи его как параметра. Возможно, вы используете зависимость через @Environment или другой механизм инъекции зависимостей. Если это так, убедитесь, что все варианты использования этих методов поддерживают новый подход.
   • Обработка ошибок: В предыдущем коде вы вызывали try? modelContext.save(), что позволяло сохранять изменения. После удаления этого вызова убедитесь, что сохранение происходит где-то еще или что это не приводит к потере изменений. Возможно, стоит добавить обработку сохранения в соответствующих местах.

2. Добавление поповера для iOS:

   • Адаптация интерфейса: Добавленный код для popover на iOS выглядит хорошо. Однако, проверьте, как он отображается на разных устройствах и ориентациях экрана. Убедитесь, что размеры и позиционирование окна поповера подходят для всех поддерживаемых устройств.
   • Поведение при разных условиях: Убедитесь, что поведение поповера совпадает с ожиданиями пользователей, особенно в сценариях, когда несколько поповеров могут быть активированы одновременно или при взаимодействии с другими элементами интерфейса.

3. Изменения в методе setDueDate:

   • Удаление modelContext: Аналогично предыдущему пункту, убедитесь, что метод setDueDate(dueDate:) может работать корректно без явной передачи modelContext. Проверьте, что все вызовы метода и его реализация учтены в этом изменении.
   • Логика установки даты: Проверьте, что логика установки даты (startOfDay и добавление дней) остается корректной и соответствует требованиям приложения после изменений.

4. Общие рекомендации:

   • Тестирование: После внесения этих изменений проведите тщательное тестирование, чтобы убедиться, что все функциональности работают как ожидается на разных платформах (iOS, macOS и т.д.).
   • Документация: Обновите документацию или комментарии в коде, если изменилась сигнатура методов или способ доступа к контексту модели. Это поможет другим разработчикам быстрее разобраться в обновлениях.
   • Кодстайл и консистентность: Убедитесь, что все изменения соответствуют общему стилю кодирования проекта и не вводят несоответствий.

В целом, изменения выглядят направленными на улучшение архитектуры и уменьшение привязки к modelContext, что является положительным шагом. Однако важно тщательно проверить, что все зависимости учтены и функциональность не нарушена.

[github-actions]

Ваши изменения демонстрируют стремление упростить методы, избавляясь от передачи ModelContext как параметра и удаления вызовов save(). Вот несколько конструктивных замечаний и предложений для улучшения:

1. Управление ModelContext:

   • Удаление параметра modelContext: Если вы убираете передачу ModelContext из методов, убедитесь, что он доступен другим способом, например, через свойство класса или синглтон. Это может улучшить читаемость, но увеличивает связанность кода и усложняет тестирование.
   • Рекомендация: Рассмотрите внедрение зависимости (Dependency Injection). Вместо использования глобального контекста, передавайте ModelContext через инициализатор или используйте контейнер зависимостей. Это повысит тестируемость и гибкость кода.

2. Удаление try? modelContext.save():

   • Сохранение данных: Удаление вызовов save() из методов может привести к отсутствию сохранения изменений, если это не реализовано в другом месте.
   • Рекомендация: Убедитесь, что вызов save() выполняется в контролирующем слое, например, в репозитории или сервисе, который отвечает за бизнес-логику. Также рассмотрите обработку ошибок при сохранении, вместо использования try?, которое подавляет ошибки и затрудняет отладку.

3. Методы reconnect и disconnect:

   • Логика соединения: Убедитесь, что при изменении связанных объектов (например, добавлении задачи в проект или родительскую задачу) контекст корректно отслеживает эти изменения.
   • Рекомендация: После модификации связей проверьте, что контекст правильно обновляет состояние объектов. Возможно, стоит добавить уведомления или использовать реактивные механизмы для отслеживания изменений.

4. Метод complete:

   • Копирование задачи: При создании копии задачи (self.copy()) убедитесь, что все необходимые свойства корректно копируются, и новая задача правильно связана с контекстом.
   • Рекомендация: Проверьте, что новая задача корректно инициализируется и что все связи (например, статус, проект) устанавливаются правильно. Также убедитесь, что копирование не приводит к дублированию данных или нарушению целостности связей.

5. Обработка повторений (repeation):

   • Логика повторения: Убедитесь, что обработка повторяющихся задач (repeation != .none) реализована корректно и учитывает все возможные сценарии повторений.
   • Рекомендация: Добавьте тесты для различных случаев повторений, чтобы гарантировать, что новые задачи создаются и связываются правильно.

6. Метод nextWeek:

   • Расчет даты: Проверьте, что расчет следующей недели учитывает все локальные особенности календаря пользователя, такие как первый день недели.
   • Рекомендация: Используйте более устойчивые методы для вычисления следующей недели, возможно, с использованием компонентов календаря или сторонних библиотек для работы с датами.

7. Метод reactivate:

   • Сброс статуса: Убедитесь, что при повторной активации задачи все связанные свойства сбрасываются корректно и нет побочных эффектов.
   • Рекомендация: Проверьте, что повторная активация задачи возвращает ее в ожидаемое состояние и что связанные объекты (например, подзадачи) также обрабатываются правильно.

8. Общие рекомендации:

   • Обработка ошибок: Вместо использования try? рассмотрите применение do-catch блоков для явной обработки ошибок при сохранении контекста. Это облегчит отладку и улучшит стабильность приложения.
   • Документация: Добавьте комментарии или документацию к методам, особенно если они выполняют сложные операции или взаимодействуют с контекстом данных.

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

[github-actions]

Ваше изменение кода демонстрирует прогресс в упрощении вызовов методов и удалении повторяющегося кода. Однако, есть несколько моментов, на которые стоит обратить внимание для улучшения качества и надежности кода:

1. Отключение правила type_body_length SwiftLint:

   • Проблема: Деактивация правила type_body_length указывает на то, что PomPadDoMacApp стал слишком длинным и, возможно, слишком сложным для поддержки.
   • Рекомендация: Разбейте PomPadDoMacApp на более мелкие компоненты или представления. Это улучшит читаемость и облегчит поддержку кода. Рассмотрите возможность создания отдельных вью или менеджеров для различных функциональностей, таких как управление задачами, приоритетами и т.д.

2. Удаление явных вызовов save() из контекста:

   • Проблема: Удаление try? sharedModelContainer.mainContext.save() из нескольких мест может привести к тому, что изменения в контексте не сохранятся, если это не обрабатывается внутри методов setDueDate, nextWeek и других.
   • Рекомендация: Убедитесь, что методы, такие как setDueDate и nextWeek, самостоятельно вызывают save() после внесения изменений в модель данных. Если save() не вызывается автоматически, изменения могут потеряться. Также рассмотрите обработку ошибок при сохранении, чтобы иметь возможность реагировать на возможные сбои.

3. Изменение сигнатур методов без передачи modelContext:

   • Проблема: Изменение методов для не требовать передачи modelContext может быть оправдано, если контекст управляется глобально или через Dependency Injection. Однако это может привести к менее явным зависимостям и усложнить тестирование.
   • Рекомендация: Если контекст данных теперь передается неявно, убедитесь, что это сделано безопасно и последовательно. Рассмотрите использование Dependency Injection или окружений (Environment) для передачи modelContext, чтобы сохранить явные зависимости и облегчить тестирование.

4. Обработка ошибок:

   • Проблема: Ранее использовался try? для сохранения контекста, что подавляло возможные ошибки. Теперь, если save() удален, важно обеспечить надежную обработку ошибок внутри методов.
   • Рекомендация: Реализуйте механизм обработки ошибок внутри методов, которые изменяют модель данных. Возможно, стоит использовать do-catch блоки и отображать пользователю уведомления о неудачных попытках сохранения.

5. Копирование и повторное подключение задач:

   • Проблема: Изменение task.copy(modelContext: sharedModelContainer.mainContext) на task.copy() и newTask.reconnect(modelContext: sharedModelContainer.mainContext) на newTask.reconnect() предполагает, что методы теперь управляют контекстом самостоятельно.
   • Рекомендация: Проверьте, что копирование и повторное подключение задач корректно обрабатываются без явного указания контекста. Убедитесь, что новые экземпляры задач правильно связаны с контекстом данных и нет утечек памяти или нарушений целостности данных.

6. Обновление интерфейса пользователя:

   • Проблема: Частые вызовы refresher.refresh.toggle() могут указывать на определенные зависимости от состояния.
   • Рекомендация: Рассмотрите использование более реактивных подходов, таких как @Published свойства в ObservableObject, чтобы автоматически обновлять интерфейс при изменениях данных, избегая необходимости вручную переключать состояние обновления.

7. Общие рекомендации по стилю и структуре:

   • Проблема: Хотя функциональность улучшена, возможны улучшения в организации кода для повышения читаемости.
   • Рекомендация: Стремитесь к разделению ответственности внутри App структуры. Например, создание отдельных менеджеров для задач, приоритетов и других компонентов может сделать код более модульным и легко поддерживаемым.

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

[github-actions]

Внесенное изменение удаляет передачу modelContext в метод disconnectFromAll(). Необходимо удостовериться, что метод disconnectFromAll() не требует контекста для корректного выполнения своей логики. Вот несколько моментов, на которые стоит обратить внимание:

1. Зависимость от ModelContext:
   Если метод disconnectFromAll() внутри использует modelContext для выполнения операций, связанных с удалением или отсоединением связей, удаление этого параметра может привести к ошибкам во время выполнения или некорректному поведению приложения.

2. Инкапсуляция логики:
   Если disconnectFromAll() теперь самостоятельно управляет контекстом, убедитесь, что это соответствует общей архитектуре приложения. В противном случае может возникнуть путаница относительно ответственности за управление контекстом.

3. Тестирование:
   После изменения метода рекомендуется провести тщательное тестирование, чтобы убедиться, что удаление параметра не нарушило существующую функциональность, особенно в случаях, когда disconnectFromAll() взаимодействует с другими частями системы.

4. Документация:
   Обновите документацию метода disconnectFromAll(), чтобы отразить изменение в его сигнатуре. Это поможет другим разработчикам понять новое поведение метода и избежать неправильного использования.

5. Обратная совместимость:
   Если disconnectFromAll() используется в других местах кода с передачей modelContext, необходимо проверить и обновить все вызовы этого метода, чтобы они соответствовали новой сигнатуре.

Рекомендации:

• Проверьте внутреннюю реализацию disconnectFromAll(), чтобы убедиться, что отсутствие modelContext не влияет на корректность работы метода.
• Если изменение необходимо и безопасно, убедитесь, что все места использования метода обновлены соответственно.
• Добавьте соответствующие тесты, чтобы подтвердить, что метод работает правильно без передачи контекста.