fix: Use simulated opaque values for TreeAdapterTypeMap

[fb55]

Opening this to have a base of discussion for #38.

This produces all of the expected type errors — see the failing tests.

[43081j]

this works for what you have because T extends TypeMap implies the default, T extends TypeMap<{[adapterKey]?: 'Document'}, ...>.

you're branding the types as a way to turn something unknown, known, i understand.

but the typemap type itself becomes meaningless and unusable:

type MyTypeMap = TreeAdapterTypeMap<
  {type: 'doc'},
  {type: 'docFrag'},
  {type: 'element'},
  {type: 'comment'},
  {type: 'text'},
  {type: 'template'},
  {type: 'docType'}
>;

declare const adapter: Adapter<MyTypeMap>;

this will error, of course, because you said extends TreeAdapterTypeMap<{[adapterKey]?: 'Document'}, ...>.

so all tree adapters now have to implement your fake adapterKey brand in order to work in the type system.

type maps unfortunately can't be made to work. i've tried many different potential solutions, and the simplest seems to be to dumb down the tree adapter interface for consumption while keeping the concrete tree adapter types rich. happy to push a branch with that once i get it building

[fb55]

so all tree adapters now have to implement your fake adapterKey brand in order to work in the type system.

They don't — have a look at the existing tree adapters. Because the key is optional, any object can be passed.

[fb55]

The downside is that a call like appendChild(parent, {foo: 'bar'}) is valid. BUT all properly created nodes will be blocked, as their [adapterKey] property doesn't match.

[43081j]

the code above does not build.

T extends TypeMap is actually constraining to the default types. this means we can't ever use any other type map, only ever those which implement the default.

interface Adapter<T extends TypeMap> {

// is the same as

interface Adapter<T extends TypeMap<
  {[adapterKey]?: 'Document'},
  ...
>> {

// this means we can only ever use type maps which ARE the default, i.e. with an adapterKey

declare const a: Adapter<TypeMap<
  {type: 'doc'},
  ...
>>; // THIS DOES NOT BUILD!

// so we MUST use the default

declare const a: Adapter<TypeMap<
  {[adapterKey]?: 'Document'; type: 'doc'},
  {[adapterKey]?: 'DocumentFragment'; type: 'docFrag'},
  {[adapterKey]?: 'Element'; type: 'element'},
  {[adapterKey]?: 'CommentNode'; type: 'comment'},
  {[adapterKey]?: 'TextNode'; type: 'text'},
  {[adapterKey]?: 'Template'; type: 'template'},
  {[adapterKey]?: 'DocumentType'; type: 'docType'}
>>; // BUILDS!

so yes, yes we do need to specify the adapter key every time we want a custom type map.

[43081j]

if you give me some time to get my branch building, i can show you my suggestion. basically, dumb down the input types and keep the concrete types strong. it means we lose some type information on the way in, but at least it would be simple and accurate.

[43081j]

i opened #43 to show what it'd look like if we just typed the generics normally.

in this solution: the typemap becomes irrelevant, as we're actually constraining on its default parameters rather than the type itself.

in the solution in #43: it is overly verbose because we need to specify all type params, every time (however that is what we should be doing really, all of this is us trying to avoid writing them all out and find a shortcut in reality)

there's also a solution somewhere i have yet to figure out: consume non-generic tree adapters but strongly type each individual tree adapter. no clue how this'd work but it sounds like there's an idea there somewhere.