Overload `map()` (and `transform()` to support object literal for specifying the transformation

[Lea Verou]

This occurred to me when reviewing #17

map() currently expects a callback, but the object literal syntax is a pretty convenient sugar for many use cases, and we could easily disambiguate between the two.

Same applies for transform() (see #20)

[Adam Janicki]

What does object literal syntax mean?

[Lea Verou]

What does object literal syntax mean?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_objects#using_object_initializers

In this case, an object of node types to functions, like the current serialize.transformations.

[Adam Janicki]

@LeaVerou Now that #29 is merged and transform can support object literals and arrays, what do we think the best approach is for map?

[Lea Verou]

@LeaVerou Now that #29 is merged and transform can support object literals and arrays, what do we think the best approach is for map?

Check out my comment in the merged PR.
Looking at the code, I just got an idea: what if we pass node as a last argument?

Then it can be nicely simple and composable:

export default function map (node, mapping, o) {
	mapping = [
		mapping,
		(node, _, _, originalNode) => originalNode === node ? {...node} : undefined
	];
	return transform(node, mapping, o);
}

Side node: not a huge fan of so many positional arguments, but worried that turning property, parent, and originalNode into a dictionary will be bad for performance since these are called a lot.

[Adam Janicki]

Check out my comment in the merged PR. Looking at the code, I just got an idea: what if we pass node as a last argument?

Yeah I saw, I will do that

Then it can be nicely simple and composable:

export default function map (node, mapping, o) {
	mapping = [
		mapping,
		(node, _, _, originalNode) => originalNode === node ? {...node} : undefined
	];
	return transform(node, mapping, o);
}

Yes, this is what I had implemented in the other PR we had previously 😄

Side node: not a huge fan of so many positional arguments, but worried that turning property, parent, and originalNode into a dictionary will be bad for performance since these are called a lot.

Hmm yeah, this is certainly a tradeoff to consider. How about we keep it as is for now (positional arguments) and revisit this later?

[Lea Verou]

Yes, this is what I had implemented in the other PR we had previously 😄

Huh, you’re right, I remembered it being a lot more complex, but the logic was basically the same.

Hmm yeah, this is certainly a tradeoff to consider. How about we keep it as is for now (positional arguments) and revisit this later?

Much harder to change API shape once stuff ships. I will mull it over.

[Adam Janicki]

Much harder to change API shape once stuff ships. I will mull it over.

Makes sense, I'll put up a PR for map, and we can decide before we merge that