Closed
Description
I needed a yaml dumper that included a replacer option similar to JSON.stringify.
This turned out to be a simple modification to js-yaml; there may be details not covered.
Its use changes the handling of undefined fields so that they are omitted from the yaml (similar to JSON).
If there is any interest in this change I will make it available.
I will probably add a reviver option for parsing.
Activity
puzrin commentedon Apr 7, 2017
I'm not sure this is needed here, but leave this open to collect feedback.
sjpt commentedon Apr 7, 2017
Thanks for the comment.
For background information: The reason we need the replacer is to prevent some objects getting placed in the output. We have an application using three.js, and many of my objects have associated THREE objects. However, when we dump the state we don't want to dump most of those, especially not the gory details of large vertex buffers, but rather recreate them after load.
We used to use JSON, but it was very noisy, especially for multiline strings with double quotes,;so awkward when we needed to edit by hand. (At least it wasn't nearly as bad as XML)
puzrin commentedon Apr 7, 2017
You could just create filtering function before calling yaml dump:
yaml.safe_dump(your_filter(data))
sjpt commentedon Apr 7, 2017
I don't want to modify my data structure or clone the major part of it; which if I understand you right is what you expect
your_filter(data)
to do? Rather, just to omit certain objects from the dump.zakhenry commentedon Jun 23, 2017
In the same boat (wanting to discard
undefined
field); it is odd that the behaviour should differ from json as yaml is supposed to be a superset of json.graphicore commentedon Jan 23, 2018
See #391 for more discussion about this topic, includes also examples. Closed because it is a duplicate.
graphicore commentedon Jan 23, 2018
Can we have this issue renamed to something like:
@sjpt I'd suggest an option like
{replacer: 'toJSON'}
to turn on the feature and to configure it.I'm still not sure if this feature is welcome.
If possible, could you please make it available as a PR (or as a branch in your fork), I'm interested in it anyways :-)
sjpt commentedon Jan 23, 2018
I'll try to make a PR soon. My replacer is like the global replacer of JSON, not like the toJSON object function. Both have their place. How about options
{replacer: globalFunction, localReplacer: 'toJSON'}
Actually, I specifically want to avoid 'toJSON' discussed in #391 as it is misused in three.js so for example
JSON.stringify(new THREE.Texture())
JSON.stringify({ x: new THREE.Texture()})
throws an exception, as does serializing anything that indirectly contains a texture unless you explicitly avoid it with a replacer. (I raised an issue there years ago and never followed it up.)
sjpt commentedon Jan 23, 2018
Pull request created, I apologize if I have not done this correctly.
graphicore commentedon Jan 24, 2018
PR is here: #392
I had a look and added some comments.
I see, you are talking about the
replacer
parameter ofJSON.stringify
. Awesome, I didn't know that :-)In this case, should I re-open #391 ?
Is that a problem of the 'toJSON' or of
three.js
. You can't avoid misuse of any API, I don't get how a bad usage of an API makes it undesirable. It's different if the API itself leads to bad design, that would be clearly a flaw. I'd like to see what's the case here, misuse of API or inherent bad API design/concept.I'm looking for good arguments not to want//have/use/pursue
toJSON
, as I'm quite in favor of it. A good argument can change my mind.Do you have a link to this issue. I'm interested in the discussion.
graphicore commentedon Jan 24, 2018
Found it: mrdoob/three.js#8428
With having an option to configure
localReplacer
this is a none-issue in here anyways. And, forthree.js
using a methodtoJSON
with different semantics thanJSON.stringify
expects, this just means that something likeJSON.stringify(new THREE.Texture())
is not a scenario intended by thethree.js
developers. Just don't do it.sjpt commentedon Jan 24, 2018
Thanks for finding that three.js issue of mine, I was about to hunt for it.
I agree that configurable localReplacer makes this a non-issue now we are using yaml rather than JSON. In fact, for us the localReplacer is not needed at all, replacer does what we need.
Also, it is easy just not to do
JSON.stringify(new THREE.Texture())
However, it is not easy to avoid an indirect equivalent, when the THREE.Texture is referenced deep down inside my own structures which I did want to JSON serialize (leaving out the references to THREE objects which we reconstruct after load).I could make a deep copy of our structure without the THREE references and then serialize that, but that is much more work
graphicore commentedon Jan 24, 2018
Not in my case, that is when the objects you serialize actually implement
toJSON
for use withJSON.stringify
.24 remaining items