Mobile and Offline Developer Guide
jNewer Version Available
Feature Limitations of Offline GraphQL
Offline GraphQL uses the same wire adapter mechanism as the standard (online only) LWC
wire adapter for GraphQL. You don’t need to change any code to use Offline GraphQL, and your
component can be used while online and offline.
However, while you don’t need to use different code, you do need to restrict the GraphQL features that you use in your queries. The Offline GraphQL wire adapter supports a subset of the features supported by the standard LWC wire adapter.
Let’s get to the largest disappointments first. There are a few major features that simply
don’t work while offline:
- 🚫 Aggregate queries
- 🚫 Mutations (data modification)
- 🚫 Pagination
Where these features are required for your component or app to function, you will need to build them yourself, or use other data access mechanisms besides GraphQL.
Data Access (Record Queries)
For “normal” data access, read only queries that retrieve record data, most features are supported. The following features are supported, but with some limitations.
- Most scalar field operators are supported:
- ✅ Boolean operators and, not, and or are supported when the nested predicates (sub-clauses) use supported features.
- ⚠️ Geolocation and other compound fields have limited support. Location-based filtering is not supported.
- ⚠️ Picklist and multi-picklist results might not exactly match results from the online implementation, particularly if null values are included in the predicate.
- ⚠️ Relative date filtering is based on the device locale, not the org locale setting.
- ✅ first argument to limit query result size is supported.
- 🚫 While first isn’t a pagination feature, it’s often used with pagination features that are not supported.
- ⚠️ scope argument:
- ✅ MINE is supported for all entities.
- ✅ ASSIGNEDTOME is supported for ServiceAppointment.
- 🚫 No other scopes are supported by Offline GraphQL.
- ✅ orderBy
- ⚠️ Ordering is supported, but can have a negative impact on performance. Keep in mind where the sorting is taking place (that is, your phone). Keep your sort criteria simple, and don’t sort more records than you need to.
- ⚠️ Ordering results by a picklist field sorts by the picklist label, rather than the order of the picklist values defined in Setup.
- ✅ Relationships and related record access:
- Parent-to-child relationships are supported.
- Child-to-parent relationships are supported.
- Polymorphic relationship fields (for example, Owner) are supported.
The following features aren’t supported at this time:
- 🚫 Compound fields (such as Account.ShippingAddress) aren’t supported in selections, predicates, or orderBy clauses.
- 🚫 Semi-join and anti-join filters (inq and ninq) aren’t supported.
- 🚫 Location-based filters aren’t supported.
- 🚫 Fiscal date literals aren’t supported in filters.
- 🚫 Relative date ranges, such as “last 30 days”, aren’t supported in filters.
- 🚫 DisplayValue for records isn’t supported. (DisplayValue for fields is supported.)
Metadata
Necessary object metadata, such as custom objects, fields, layouts, and so on, is
automatically loaded and cached during priming and online activity. GraphQL lets you manually
query for metadata when the occasion calls for it. When offline, there are some limitations.
- ⚠️ Metadata fetched through GraphQL is cached separately from metadata fetched through the getObjectInfo wire adapter. They might not always be perfectly in sync.
- ⚠️ Related list metadata might work, but is unsupported at this time.
Other Feature Considerations
- Record query pagination:
- 🚫 The after argument to paginate results isn’t supported.
- 🚫 Cursor field selections aren’t supported.
- ⚠️ GraphQL query performance can be suboptimal on complex queries that filter or order by non-indexed fields.
- ⚠️ Queries that reference offline-created (draft) records in the predicate (directly in the query, or indirectly through variables) return locally cached results only. The query won’t make a network request to the server.