Collection reference from useQuery() not updating w/o dep. list

[elle-j]

This is regarding React (not React Native) and our WASM build.

Dependencies Used

• @realm/[email protected]
• [email protected]

Problem

The following code works as expected in React Native but not in React:

const tasks = useQuery(Task);

Behavior:

• When toggling or deleting a task, the tasks reference should be updated (it should be a new reference), but the reference does not get updated. Thus, the React component does not rerender.
• @realm/react expectedly executes these lines:
  

  realm-js/packages/realm-react/src/cachedCollection.ts

  Lines 169 to 170 in 28a50dc

  	updatedRef.current = true;
  	updateCallback();

• @realm/react unexpectedly does not enter this if-block:
  

  realm-js/packages/realm-react/src/useQuery.tsx

  Lines 90 to 93 in 28a50dc

  	if (updatedRef.current) {
  	updatedRef.current = false;
  	collectionRef.current = new Proxy(collection as Realm.Results<T & Realm.Object>, {});
  	}

Workaround

The following code is a temporary solution users can implement as a workaround:

const [requeryFlag, setRequeryFlag] = useState(false);
const tasks = useQuery(Task, (collection) => collection, [requeryFlag]);
useEffect(() => {
  // The value doesn't matter, only that it is different from the initial value.
  setRequeryFlag(true);
}, []); // <-- Only on mount is needed

Note that the useEffect() only needs to run on mount for useQuery() to correctly update.

Reproduce

Minimal local Realm app to reproduce the behavior: react-userquery-bug.zip

Notes

This issue does not seem to appear in React Native.

[CatoPaus]

This is regarding React (not React Native) and our WASM build.

Dependencies Used

• @realm/[email protected]
• [email protected]

Problem

The following code doesn't work in React:
const task= useObject(Task, new BSON.ObjectId(user.id));

@elle-j FYI: I see the same issue on useObject() But if I place useObject() in the same hook together withuseQuery(), and use the workaround, it works as expected.

[elle-j]

@CatoPaus, thanks for the additional information! We'll make sure to fix both use cases once we get to this issue.