The `configuration` vs `deepConfiguration`

[danielkcz]

Up until now this was truly a mystery what is that thing good for. Now thanks to @koresar new episode on Fun with Stamps this has finally become bit more clear.

Perhaps I am still missing some details, but I think its wrong having both of them there. Let me quote here example from the article

const SomeDeepConfiguration = compose({deepConfiguration: {
  some: ['data']
}});
const MoarDeepConfiguration = compose({deepConfiguration: {
  some: ['moar data']
}});
const HaveBoth = compose(
  SomeDeepConfiguration, MoarDeepConfiguration);
console.log(HaveBoth.compose.deepConfiguration);

Now imagine that first stamp would just use configuration instead of deepConfiguration. Suddenly there is big confusion because the configuration is in other object. Obviously this is trivial example, but in case you have bunch more stamps that are composed together, it makes it not that useful as for some values you will check one property, for something else it will be in other one.

Would it make more sense to have just one configuration which would be deeply merged? I mean so far I haven't found use case where I would actually use configuration except collision-stamp, but in there I don't actually see the configuration to be used there, so I bit clueless.

[JosephClay]

I see deepConfiguration as a handy tool for composing objects that Class doesn't offer. There's no more confusion here than any other order-of-operation dependent behavior.

configuration behaves like Object.assign so there's parity with the language.

Deep by default would be a huge perf hit as well.

[danielkcz]

I understand differences, it's just that you have to always remember if you have used deep for that particular configuration value or not.

Huge perf hit is surely relative, depends on how much of data you would be storing there.

[JosephClay]

I understand differences, it's just that you have to always remember if you have used deep for that particular configuration value or not.

No more than remembering to use _.merge instead of _.assign.

The inverse can also be problematic, if I expect the array to be overwritten instead of merged.