Allow elements to define attribute lists of refracted elements

[danielgtaylor]

This creates a new variable that can be used to define the attribute key names which are made up of non-refracted lists of refracted elements, such as source maps. It adds a test to the subclassing example to maintain code coverage. Since the sourceMap element isn't defined I have created the test with an array of string elements instead. Serialization and deserialization work for both full and compact refract.

This change will allow me to update the parse result namespace and unblock some development of source maps. The other potential blocker is how to treat e.g. element.meta.title as an element with a source map rather than a string, but let's leave that for another PR.

cc @smizell

[smizell]

@danielgtaylor LGTM

I think we should say this feature may not be supported in the future, so tread lightly :)

It almost feels like we could provide some pre-conversion hook for user to use when they have these kinds of scenarios, because there will be more cases that we can't automate like this. Thoughts?

[smizell]

👍

[pksunkara]

Let's take the example of source maps. Why do we have to say it is a non-refracted array of refract elements? Why can't we simply say that it is a refract array element but serialising it should print plain array.

Basically, we really need to define the serialization formats rather than doing something like this.

[danielgtaylor]

@pksunkara this should help: refractproject/rfcs#29