- From: Marcos Cáceres via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 Apr 2024 02:50:48 +0000
- To: public-geolocation@w3.org
> I'm writing up the "Intent to Prototype and Ship" email for the Blink launch process and I just want to make sure I understand the motivation for this change. The primary motivation was to make it easier for developers to (re)use and serialize these objects. ```JS await position = new Promise(r => navigator.getCurrentPosition(r)); await fetch('https://example.com/api/positions', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(position.toJSON(), null, 2) }); ``` And then it just happens that we can potentially reuse `.coords.toJSON()` for something like #146. > Are tests planning to use JSON.stringify() or is it that much easier to compare objects when they are "plain old JavaScript objects" than when they are instances of a WebIDL interface? It's simpler to compare object's expected values than JSON.stringify() for the reasons you discovered. > I noted when I was writing tests for this change in Chromium that the output of JSON.stringify() is not well defined (due to property order) so it doesn't seem appropriate for tests. Yeah, I concluded the same thing. You can see how I tested in WebKit: https://github.com/WebKit/WebKit/pull/27063/files#diff-7531c0af803badf851f88a70c6702ee38c2936b1a42342e0430a3605befaf5b7 But the only interesting part is (overlook the fact that they are on the global object, that's just a WebKit testing framework thing): ```JS // We use "actual" for future proofing on purpose, in case more properties get added to the interface. for (const key in window.actual) { shouldBe(`window.actual.${key}`, `window.expected.${key}`); } ``` -- GitHub Notification of comment by marcoscaceres Please view or discuss this issue at https://github.com/w3c/geolocation-api/pull/147#issuecomment-2050871040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 12 April 2024 02:50:49 UTC