You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As currently proposed, JSON modules have a default export and no other exports, where the default export is the object resulting from parsing the module's content as JSON, like what you'd get from JSON.parse(). In the July TC39 meeting (notes here) @rricard and @erights expressed interest in exporting Records/Tuples instead of an object.
Pro: For folks in favor of #1 , the immutability is a positive. IMO exporting as Record/Tuple is a nicer way of achieving immutability than doing Object.freeze under the hood, although as I stated in the other Issue I'm not convinced that immutability is a requirement. Con: People have long-standing historical expectations that JSON is an Object (I think @bmeck raised a point like this during the meeting). Any change where JSON modules produce something fundamentally different from JSON.parse() could be a source of confusion and even a drag on adoption. My expectation had been that developers would be able to straightforwardly swap out parts of their code that did thinks like fetch() content that gets fed to JSON.parse() and replace with a simpler import of a JSON module. The more that JSON.parse() differs from JSON modules, the harder this gets. Then again, I see that JSON.parseImmutable() is also proposed so perhaps one could argue that we're looking to expand the expectations about what JSON should be in JS and that long-term this isn't a concern.
Thoughts? I guess this whole issue is contingent on the discussion at #1 about whether JSON modules should be immutable in the first place, so maybe that needs to be decided first.
The text was updated successfully, but these errors were encountered:
I will restate; I think the biggest issue is that various tools already load JSON as Objects. I do not think it appropriate to alter that de-facto output / expectation from tooling, but do think any sort of new expectations can just use a new attribute to flag the import for specialized evaluation.
I think it would be worth investigating having a new module attribute kind for loading JSON as immutable, e.g. import config from "./config.json" with { kind: "immutable" } assert { type: "json" };.
This however would probably need to create a second module record, although it could re-use the same backing json string so it's probably not a big deal.
As currently proposed, JSON modules have a default export and no other exports, where the default export is the object resulting from parsing the module's content as JSON, like what you'd get from JSON.parse(). In the July TC39 meeting (notes here) @rricard and @erights expressed interest in exporting Records/Tuples instead of an object.
Pro: For folks in favor of #1 , the immutability is a positive. IMO exporting as Record/Tuple is a nicer way of achieving immutability than doing
Object.freeze
under the hood, although as I stated in the other Issue I'm not convinced that immutability is a requirement.Con: People have long-standing historical expectations that JSON is an Object (I think @bmeck raised a point like this during the meeting). Any change where JSON modules produce something fundamentally different from JSON.parse() could be a source of confusion and even a drag on adoption. My expectation had been that developers would be able to straightforwardly swap out parts of their code that did thinks like
fetch()
content that gets fed toJSON.parse()
and replace with a simplerimport
of a JSON module. The more thatJSON.parse()
differs from JSON modules, the harder this gets. Then again, I see thatJSON.parseImmutable()
is also proposed so perhaps one could argue that we're looking to expand the expectations about what JSON should be in JS and that long-term this isn't a concern.Thoughts? I guess this whole issue is contingent on the discussion at #1 about whether JSON modules should be immutable in the first place, so maybe that needs to be decided first.
The text was updated successfully, but these errors were encountered: