Allow multiple barcodes to be decoded

[dgreif]

I have added an additional configuration to the decoder section called multiple. If it is set to true, the decoder will not return after the first valid result. The result object that gets emitted is slightly different for the end user since it has multiple barcodes on it.

[dgreif]

I also tweaked the packages and lint. There were some duplicates in each, and no way to run lint from command line that I could see.

[serratus]

Please wrap your lines at 80 chars

[dgreif]

Done. Sorry about that, didn't notice the pattern 😄

[serratus]

The detected event is not fired any more when multiple is activated. Maybe you could expand the condition to include something like: result.barcodes && result.barcodes.length > 0 . And since you only add the results to this array if the decoding was successful, this should be sufficient.

[dgreif]

I must have overlooked the last part of that method the first time through, good catch. I just pushed a fix for it which also future-proofs the check if we decide to return an array instead of an object. I'm making the assumption that some of the barcodes might not have a codeResult instead of just checking barcodes.length. If you agree that's the way we should go I will commit the array result change.

[serratus]

Thanks for the PR. I've just tried it, and it works thus far. I noticed that you are wrapping the result in an object with a single key named barcodes. Instead, we could simply publish an Array and use that on the other end of the API? Meaning, that if you turn on the multiple flag, the user gets an array as a result. What do you think?

[dgreif]

Great suggestion. I originally had the same idea, but realized that we would then loose the ability to add boxes to the results. Since not all of the boxes will end up with a valid barcode result, I thought it made sense to return both the boxes and the barcodes on an object. One alternative would be to always add an object to the array for each box, and that object would either have a codeResult or not depending on the outcome of decoding. If that's the route you want to go, I can definitely make those changes.

[serratus]

From my point of view, separating the boxes and the results might also be a good idea, since the list of boxes is the same for each result. I would even go that far that we could always return an array of results and the consumer of the API then have to deal with that.

Example of a proposed result object:

{
  "barcodes": [{
    "codeResult": {},
    "line": [],
    "angle": -0.6565217179979483,
    "pattern": [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, /* ... */ 1],
    "box": [],
  }],
  "boxes": [
    [],
    []
  ]
}

But maybe this can be implemented in the future. Depending on your response, I will merge the the pull-request either now, later.

[dgreif]

I went ahead and pushed my change that returns an array instead of an object. After thinking about it more, I think it makes more sense than separating them because with just one array we don't have to duplicate the boxes between boxes and each barcode result (each had their individual box). If they are all in the single array it is really easy to see which boxes had a codeResult and which did not.