Add a bodyxml->content-tree converter

[chee]

This is only made to deal with very simple articles so far that contain basic html content.

I need to do a little more research to understand what <content type=content and <content type=article are.

It passes the simple-post test but not the kitchen-snippet test.

The transformer API is fine, i guess. you write something like this:

["pull-quote"](pq) {
	let text = find(pq, {name: "pull-quote-text"})
	let source = find(pq, {name: "pull-quote-source"})
	return {
		type: "pullquote",
		text: text ? xastToString(text) : "",
		source: source ? xastToString(source) : "",
		children: null,
	}
}

if you return a children value, it'll recurse into the children of the xmlnode to make the children. if you return a children value, it won't. if you return children: null it won't go to the children but also the children will be deleted from the node.

hope u like it!

[adgad]

API looks okay to me so far. the ones are gonna be interesting, I reckon there are ones that behave differently depending the attributes (e.g. flourish i think has type Content, and a data-asset-type=\"flourish\"

I guess that can still work though, we can return different things inside the transformer function depending on what the attribute is.

[adgad]

😭

[chee]

API looks okay to me so far. the ones are gonna be interesting, I reckon there are ones that behave differently depending the attributes (e.g. flourish i think has type Content, and a data-asset-type=\"flourish\"

I guess that can still work though, we can return different things inside the transformer function depending on what the attribute is.

i kept making the API more powerful and then stripping it away when none of the nodes i was working with needed the power. but it's possible that the transformer function needs to take a second arg of walk() which'll let them take care of their own children and allow the main walk() loop to know less about the different kinds of nodes

[chee]

API looks okay to me so far. the ones are gonna be interesting, I reckon there are ones that behave differently depending the attributes (e.g. flourish i think has type Content, and a data-asset-type=\"flourish\"
I guess that can still work though, we can return different things inside the transformer function depending on what the attribute is.

i kept making the API more powerful and then stripping it away when none of the nodes i was working with needed the power. but it's possible that the transformer function needs to take a second arg of walk() which'll let them take care of their own children and allow the main walk() loop to know less about the different kinds of nodes

another option is to make the code more about mutating the existing tree than generating a new one. that's probably how we'd do this if we weren't javascript programmers. that code would look more like using unist-util-visit, with the return value being used to decide how or if to recurse.

[chee]

i should add some more tests. hopefully i can get a hold of some specialist content soon to use as a source of tests

[chee]

for more complicated transforms like the ones in cp we might need to provide the parent node to the transformer function as a second arg

[chee]

once this is merged i'll go ahead and enact the filesystem changes described in a comment on eli's PR because we've confirmed we can make that work using a go.mod file in the root of the repo beside the root package.json.

then we can start working towards a world where this repo can publish packages.

[adgad]

Happy to approve this! I guess the proof in the pudding will be once we're able to publish it as a package and @vbachev and co can start using it 🍿