Handling NDEFRecord

[zolkis]

@sleevi notes here:

The only other bit I would flag, and I fully admit I'm not an expert here and so you'll want to find someone better versed in the Web Platform idioms, is where/how an error should be signaled for an unsupported recordType. Right now, if I understand correctly, I can create a 'valid' NDEFRecord via NDEFRecordInit, but whose recordType is invalid/unparsable. That error is not actually signaled back to the consumer until they try NDEFWriter.push, which invokes the create NDEF message algorithm, which invokes create NDEF record, which invokes validate external type.

Because you expose the constructor for NDEFRecord, should you be parsing/validating the type then? The URL class, for better or worse, has setters which do the parsing/validation. I'm not sure why the NDEFRecord type is read-only (maybe that's the current best practice), but it seems that you at least want to validate during that constructor as well, to ensure a client only encounters well-formed NDEFRecords

In principle we create NDEFRecord only when reading and we use NDEFRecordInit in push().

However, you are right that clients could just construct an NDEFRecord and that may warrant validation. Not that there is much they could do with them, since push will treat them as NDEFRecordInitand will create a new NDEFRecord out of them before pushing.

@kenchris @beaufortfrancois please advise.

[beaufortfrancois]

For what it's worth, current implementation of Web NFC in Chromium raises a TypeError when NDEFRecord is constructed with invalid arguments.

new NDEFRecord({ recordType: "foo" });
> VM89:2 Uncaught TypeError: Failed to construct 'NDEFRecord': Invalid NDEFRecord type.

[kenchris]

The ctor of NDEFRecord takes an NDEFRecordInit, so isn't it handled then?

[rakuco]

For what it's worth, current implementation of Web NFC in Chromium raises a TypeError when NDEFRecord is constructed with invalid arguments.

See also: #622