autocomplete: Add and test MentionAutocompleteView

[chrisbobbe]

Thanks @gnprice for demonstrating tests for this tricky async logic (and also guiding its implementation)! I've added some more tests in this revision:

test('MentionAutocompleteView yield between batches of 1000', () async {

test('MentionAutocompleteView new query during computation replaces old', () async {

test('MentionAutocompleteView mutating store.users while in progress causes retry', () async {

and kept the "DEV DEMO" commit from my earlier draft in case that's convenient for more manual testing. (Marking as a draft just because of that commit.)

[gnprice]

Thanks! Small comments below, mostly about the tests.

I think after those are resolved, it'd make sense to merge this (sans the demo commit). Then probably next is to build a UI for it, and that'll be enough for #49.

We can then file a followup issue for coming back to support wildcards and user groups, as well as other ways of matching queries to users or ranking matches.

[gnprice]

nit:

Suggested change

	final Map<int, List<String>> _nameWordsByUser = {};
	List<String> nameWordsForUser(User user) {
	return _nameWordsByUser[user.userId] ??= user.fullName.toLowerCase().split(' ');
	}
	invalidateUser(int userId) {
	final Map<int, List<String>> _nameWordsByUser = {};
	List<String> nameWordsForUser(User user) {
	return _nameWordsByUser[user.userId] ??= user.fullName.toLowerCase().split(' ');
	}
	invalidateUser(int userId) {

[gnprice]

Suggested change

	invalidateUser(int userId) {
	_nameWordsByUser.remove(userId);
	void invalidateUser(int userId) {
	_nameWordsByUser.remove(userId);

[gnprice]

Co-authored-by: Greg Price <[email protected]>

should be greg@, not gnprice@ :)

[chrisbobbe]

Ah, haha yeah that's right! I've sometimes wondered whether it would have been neater if I took chris@, especially if I was the first to break the pattern of using just a first name.

[gnprice]

should pull these .has calls out into a little extension, similar to #94 (comment)

Here, as a bonus that will dedupe them.

[gnprice]

Let's make this a less round number, like 2500. That will make it easier to reason through why the number of yields below is what it is, because it will avoid any fencepost questions — questions like whether another yield becomes involved when the number of users reaches 3000, or when it exceeds 3000.

(The answer turns out to be "reaches" — so if this becomes "< 2999", then we need one fewer yield below.)

[gnprice]

similarly, make this 1500 or 2500

[chrisbobbe]

Thanks for the review! Revision pushed.

[gnprice]

Thanks! Looks good; merging.

[gnprice]

(FWIW I'd be inclined to put this one inside the individual test file, down at the end after main, because it seems likely we'll only want it within the one file and because it'd be easy to move later if we want it in several files after all. But in a separate file is fine too.)