Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for extensions parsing #5

Merged
merged 4 commits into from
Jul 30, 2018
Merged

Conversation

vicjune
Copy link
Contributor

@vicjune vicjune commented Jul 26, 2018

Improved the parsing of adbreak extensions contained in the VMAP response.

Since no guidelines are specified for the content of extensions, the XML is parsed recursively with all its children

const vmap = new VMAP(xml);
const vmapWithExtensions = new VMAP(xmlWithExtensions);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's move the init setup for vmapWithExtensions directly inside the describe('Ad break with extensions' block

</vmap:TrackingEvents>
</vmap:AdBreak>

<vmap:AdBreak breakType="linear" breakId="myid" timeOffset="00:10:23.125">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can remove these other adbreaks from this test xml. In the end we just need an xml with an adbreak which contains extensions

const nodeAttr = nodeAttrs[nodeAttrKey];

if (nodeAttr.nodeName && nodeAttr.nodeValue) {
if (!parsedNode.attributes) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can avoid this check everytime by initializing parsedNode like this:

const parsedNode = {
  attributes: {}
};

.forEach(childNode => {
if (!parsedNode.children) {
parsedNode.children = {};
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above, plus I think it would be more consistent if this method returns everytime an object with the same structure.

So we can define its general structure on top and later add attributes and children in case there are some.

src/adbreak.js Outdated
@@ -30,7 +31,9 @@ class VMAPAdBreak {
}
break;
case 'Extensions':
this.extensions = node.childNodes;
this.extensions = childrenByName(node, 'vmap:Extension').map(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put this as a reminder: since other parts of the parser still use node.localName, which is a deprecated property of the Node we api, we should always use node.nodeName plus this new helper function when possible.

see https://developer.mozilla.org/en-US/docs/Web/API/Node/localName

And maybe we can "tune" the childrenByName utility name to accept a name without the vmap: prefix and automatically search for children with and without the prefix

@@ -0,0 +1,78 @@
/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should add unit tests for all this methods too :p

To be sure their behaviour is correct one by one

}

/**
* Parses a node text (for legacy support).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which legacy support?

for (let nodeAttrKey in nodeAttrs) {
const nodeAttr = nodeAttrs[nodeAttrKey];

if (nodeAttr.nodeName && nodeAttr.nodeValue) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if nodeAttr.nodeValue === 0? probably 0, false, ... are values we want to parse no?

@eliamaino-fp
Copy link
Contributor

Looks good. We just need to use the new format here too https://github.com/dailymotion/vmap-js/blob/master/src/vmap.js#L24

And to update the README documentation explaining the new structure for extensions

Copy link
Contributor

@eliamaino-fp eliamaino-fp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, ready to ship 🚢 :shipit:

@eliamaino-fp eliamaino-fp merged commit 7d09df0 into master Jul 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

2 participants