Improve message path autocomplete logic

[foxymiles]

User-Facing Changes
This improves message path autocomplete suggestions.

Description
Currently we offer unhelpful message path autocomplete suggestions across arrays of message objects when they contain fields that we mistakenly identify as numeric ids. For example trying to treat the child_frame_id field of a transform as a numeric id. The solution in this PR is to check the datatype of that *_id field and only offer autocomplete values of *_id==0 if *_id is a primitive integer type.

Fixes #2997

[jtbandes]

I'm a little confused about how this interacts with the code that does getExamplePrimitive:

studio/packages/studio-base/src/components/MessagePathSyntax/MessagePathInput.tsx

Line 331 in 974954b

items.push(`${name}==${getExamplePrimitive(item.primitiveType)}`);

I guess only one of these code paths is taken, based on whether a full recognized topic has been typed already? Anyway, it seems like we should at least try to use the same getExamplePrimitive function here if it makes sense... maybe there's something I am missing though.

[foxymiles]

Yeah this entire code path only runs if isTypicalFilterName is true:

studio/packages/studio-base/src/components/MessagePathSyntax/isTypicalFilterName.ts

Lines 16 to 18 in ac261c6

	export function isTypicalFilterName(name: string): boolean {
	return /^id$|_id$|I[dD]$/.test(name);
	}

Basically it's trying to find something that looks like an integer id and complete on it, which doesn't make sense for floats, whereas getExamplePrimitive doesn't discriminate ints from floats.

[jtbandes]

It could be a string id too though (like frame_id). It doesn't seem necessary to couple the isTypicalFilterName heuristic with which types are supported in this case. Though I'm not suggesting adding more logic, I'm suggesting reusing the existing logic to simplify things a bit. Does that seem possible?

[foxymiles]

Yeah the point of the followup logic there is to not try to autocomplete on a string _id. I'm not sure if I follow what you're suggesting by reusing the existing logic. Could you expand on what you have in mind a little?

[jtbandes]

I guess I meant instead of adding the structureItemIsIntegerPrimitive check, just call getExamplePrimitive which will handle integers as well as other types that the selected field might have. Why wouldn't we want to offer autocomplete on string ids?

[foxymiles]

Because this code doesn't have any knowledge of the contents of messages we've seen yet so it doesn't know what kind of string ids it could suggest.

[foxymiles]

One could also make a strong case for just getting rid of this logic that tries to do a special case autocomplete on an array of items with a field like *_id.

[jtbandes]

I think suggesting an empty string =="" is more useful than showing nothing at all because it shows the user the correct syntax.

I don't feel too strongly about keeping this logic but I do think it will become harder to discover the filter syntax if it never shows up in the autocomplete.

[foxymiles]

At least in the case of arrays, which this code is special cased for, maybe it's better to just suggest [0]?

[foxymiles]

And I think suggesting =="" for a string field is non-ideal because it seems to me like we want all the autocomplete suggests to actually result in a message path with data if a user clicks or selects it, not something that requires further editing.

[jtbandes]

Leaving it up to you whether to make any changes based on above discussion or keep the PR as-is.