# Query, Filter, and Refresh Events

## Content

Use this topic when the application needs to find a subset of events, filter the schedule by business criteria, or refresh Scheduler after data changes. These are runtime data operations; event field mapping is covered in [Configure Event Data](/wijmo/docs/Topics/scheduler/configure-event-data).

## Query events by date and resource

Use `getEvents` when an application command needs source events in a time range or resource scope. Resource conditions are passed as a `SchedulerResourceQuery` array.

```ts
const visibleEvents = scheduler.getEvents(
  new Date(2026, 7, 24),
  new Date(2026, 7, 25),
  [{ fieldExpr: 'roomId', value: 'room-a' }],
);
```

The returned values are the original source items, not rendered event fragments. The `start` boundary is inclusive and the `end` boundary is exclusive.

## Filter events with `CollectionView`

Use a `CollectionView` filter when users should see only events that satisfy an application condition, such as status, team, owner, or a search term.

```ts
const events = new wjCore.CollectionView(allEvents);
scheduler.itemsSource = events;
events.filter = item =>
  item.status === 'Confirmed' && item.team === selectedTeam;
```

Changing the filter refreshes the collection view. Scheduler renders the current view of the collection and does not modify the original array.

## Combine search and filter conditions

Keep the filter predicate in application state so search text and selection controls are applied consistently.

```ts
function refreshFilter() {
  const term = searchText.trim().toLowerCase();
  events.filter = item => {
    const matchesText = !term || item.subject.toLowerCase().includes(term);
    const matchesStatus = statusFilter === 'All' || item.status === statusFilter;
    return matchesText && matchesStatus;
  };
}
```

Use resource descriptors when the requirement is to display resource lanes or evaluate resource assignments. Do not use a collection filter as a replacement for resource configuration.

## Refresh after local changes

Add, edit, or remove items through the bound `CollectionView` so Scheduler receives collection notifications.

```ts
events.addNew(newEvent);
events.commitNew();
```

For edits, update the source item through the collection APIs described in [Create, Edit, and Delete Events](/wijmo/docs/Topics/scheduler/create--edit--and-delete-events). Avoid changing rendered event elements directly.

## Refresh after server updates

After a service request completes, replace or update the collection source and then refresh the view. Reconcile failed requests in application code because Scheduler does not roll back a server operation automatically.

```ts
const response = await api.getEvents();
events.sourceCollection = response.items;
events.refresh();
```

When updates arrive incrementally, apply them to the existing collection instead of replacing the entire source. This preserves the collection instance used by filters and other controls.

## Keep Scheduler and application state synchronized

| Operation | Recommended owner |
| --------- | ----------------- |
| Field mapping and validation | Application and Scheduler configuration |
| Search and business filtering | `CollectionView` or application state |
| Date and resource lookup | `getEvents` |
| Local collection notification | `CollectionView` |
| Server persistence | Application service layer |

For field mapping rules, see [Configure Event Data](/wijmo/docs/Topics/scheduler/configure-event-data). For persistence after user edits, see [Create, Edit, and Delete Events](/wijmo/docs/Topics/scheduler/create--edit--and-delete-events).