Error using Set and Map state properties in TypeScript

[aelr]

First of all, this library is amazing.

Secondly, using a Set or Map as a property for State produces an error:

    const [a, setA] = createState({property: new Set<string>()});
    const aProperty: Set<string> = a.property;

    const [b, setB] = createState({property: new Map<string, string>()});
    const bProperty: Map<string, string> = b.property;

For Set:

Type 'State<Set<string>>' is missing the following properties from type 'Set<string>': [Symbol.iterator], [Symbol.toStringTag]ts(2739)

For Map:

Type 'State<Map<string, string>>' is missing the following properties from type 'Map<string, string>': [Symbol.iterator], [Symbol.toStringTag]ts(2739)

Is this something missing in the Types?

[ryansolid]

Interesting. Likely. I'm not the best at TypeScript but I'd think it would pass through the definition pretty transparently. Symbols aren't making it through though it looks like. It looks like atleast one of my resident TypeScript gurus had hit something similar to this before looking at a comment on the source code. As usual it links back to an issue with TypeScript: microsoft/TypeScript#24622. Not sure what the generic solution for now would looks like. Calling on the TypeScript experts to help with this one.

Admittedly personal I haven't hit this case since I don't currently do anything with Maps or Sets. I don't have Observable Maps or Sets so I tend to not use them in State but it's still interesting since I suppose other objects could have similar issues perhaps.

My main reason for not implementing observable Maps or Sets is I haven't figured out exactly what desirable behavior would be and having non "state" infectiously observable objects is not something that I have worked out. Like should the contents of these be proxies, simple signals etc.. The other interesting part is the way Solid State works, other than getters the internal proxy target in Solid is a POJO. The internal signals are linked like a secondary tree. For Maps or Sets to work they would be in the target which is inconsistent as they would be innately reactive. This brings reasonable amount of complexity. So even if I were to introduce them I'm not sure they'd just show up in State without explicit wrapping.

I'm always looking for use cases. So if I can understand what you'd want to do with the Map and what is reasonable criteria for tracking it will help figure me work out a good approach to take with them.

[aelr]

Thanks for the detailed insight. Part of why I filed this was to understand the expectations around Sets and Maps. For my case, I planned to use the Set as an immutable object, with no expectation of reactivity on add/delete. For now, I'll either use an Array instead with a Memo to generate the Set or switch to a POJO keyed on object IDs.

[ryansolid]

To be fair regardless there is Type bug here. Not quite sure best solution yet but this should still work as you've described and it does without TypeScript. There might be a way of infering symbols and forwarding them through.