Support for bracket-accessed object property autocompletion.

[a3kov]

Recently bracket syntax fix was added in #13. Now would be nice to have full autocomplete support for this type of object access, when we type some.objects[0]. in the following example

{{ some.objects[0].name }}

We must be able to distinguish array access from property access - probably using numeric key would be enough.

There is also map-like access pattern, which can be used for function calling without creating custom filters (very useful because I think it supports variable keys).

{{ some.objects["foo"].name }}

When used with literal key it is possible to infer the resulting object type and to suggest properties, when we type some.objects["foo"].
Now, if the key was a variable instead of a literal I guess that would be impossible ? But if we could get the literal working that would be awesome.
I think map-like literal access should be distinguishable from dot property access, because they are not the same thing, but I'm open to hear other people's opinions on this.

[marijnh]

Right, that'd be good to support. Would using "[]" as the path element for dynamic subscripts, as in attached patch, work for you? Then the type of a path can continue to just be string[].

[a3kov]

Sorry I'm not very experienced with TS, do I understand it correctly ?

• for array index access obj[1] we get "[]" path item
• for literal map-like access obj["some"] we get "some" path item
• for variable map-like access obj[somevar] we also get "[]" path item

[marijnh]

Well, ["obj", "[]"] and ["obj", "some"], but otherwise, yes, that's how it works.

[a3kov]

Would it be possible to have brackets together with the original key ? I.e. [1], ["some"] and [somevar] as path items ? This way we can distinguish them from the property access and the resolving function can perform additional parsing for more precise suggestions. I'm not sure it would be strictly better overall, but at least we wouldn't be losing information along the way.

[marijnh]

That doesn't sound very useful. ["some"] is equivalent to .some, and thus it makes sense to represent it the same way. When the index is a dynamic expression, there's not much you can do with it.

[a3kov]

["some"] is equivalent to .some

I don't believe this is true. Properties are very strictly defined in Liquid - you can't just have a random character as a part of it's name. OTOH inside a string you can have anything. I've mentioned function calling before.

When the index is a dynamic expression, there's not much you can do with it.

If you have type system backing it, you can infer the type of the key and return different results based on the type. Just an example.. Liquid in general is not a strictly defined system and there are some creative implementations that use (abuse) things like this.

[a3kov]

2 examples of Liquid implementations, where arbitrary string keys are used:
https://learn.mechanic.dev/platform/liquid/keyword-literals/hash
https://help.prefinery.com/article/41-liquid-programming-guide

In general, Liquid is just a theater for users. It's not a real programming language with strict types - how things work behind the scenes and how things are presented in Liquid don't have to be the same. There's no reason to lock ourselves into "keys must be object properties" assumption.

[marijnh]

I'm not really interested in a discussion about the nature of keys in Liquid here. You yourself suggested string literal keys to be read as their content, which seems like a reasonable thing to do. The system I implemented seems powerful enough to provide contextual completion even through number indices and such, so I'm going to just keep it the way it works now.

[a3kov]

That is very sad to hear.

You yourself suggested string literal keys to be read as their content, which seems like a reasonable thing to do

I'm sorry I wasn't clear enough in my initial message, but I also provided enough arguments for this in the following messages.
Without being able to distinguish map-like access from property access there's no good way to implement map (called hash in the linked examples) data types. Users would need to fork this library.