If we do this, I guess to_json should also take this into account.

I'm not sure if this feature is a good idea.

What's the use case? Why do we need this in JSON.mapping? To me it doesn't seem to be commonly needed. And it's relatively easy to implement in a custom to_json method.

There are ideas to change the way mappings are defined by using meta attributes (see #3620) which will probably mean removing JSON.mapping at some point. It is still open how a future solution will look like. Unless there is a pressing reason to implement this, it might make sense to figure out the general mechanics first.

For me, this is often needed, and needed mostly for from_json method (not to_json). When you have api, which receive some defined data structure, it also sometimes add not defined fields (different every time), which you want to receive. Before that, there is only way to parse it manually, which is pain.

which you want to receive

Pardon me insisting, but why? You described how this is used (which is quite obvious) but not a real reason.

there is only way to parse it manually, which is pain.

Would it perhaps be an option to improve the manual implementation and make it easier to use?

Sometimes third-party api send such json, and you should process it correctly. I not think that manually parse ~30 fields with JSON::Any would be fun.

I'm still not convinced this is useful enough. But I don't have to decide that either ;)

But I have an idea to solve your problem in a more general and less intrusive way: JSON.mapping could have more advanced handling of keys not included in the mapping (the else branch in the big case statement produced by the macro). Currently, there is strict which configures to either raise or skip. What if there was a third way, a custom handler?

JSON.mapping(strict: ->(key : String, parser : JSON::PullParser) { @extras[key] = JSON::Any.new(parser) })

This needs only one little change in JSON.mapping and is a far more versatile solution. You can even raise for specific conditions.

callback is nice, but there is also should be way to extend to_json method. May be

to_json(js) { |js| @extras.each { |k, v| js.field(key) { v.to_json(js) } } }

Implementing a custom to_json is much easier than parsing.

so, should i implement callback? or it not decided.

The idea of a callback is nice. Maybe JSON.mapping could define a method that by default raises an error, and which you can override to deserialize unknown keys. And same goes for to_json.

If eventually we have meta attributes, it would work the same way.

But let's first design it: what's the name of the method, etc.

fixed by serializable