Also flattens cats 🐈 about safe-flat HOT 8 CLOSED

@ZitRos I guess my question would be why would you pass an object you don't want to be flattened to a flatten function? I'm not sure that I see that as a real use case.

from safe-flat.

@jessie-codes +1 to @ZitRos there's gotta be a way to not flatten things. Maybe a function in user passed options to test if the condition is met continue flattening for values or else stop for that particular node.

from safe-flat.

from safe-flat.

To bring one more solid argument,

From the pure JavaScript perspective, why for instance the library doesn't flatten Date object? Perhaps Buffer object? BigInt? You don't flatten those intentionally, right?

What if web standards bring more objects like these in the future? Perhaps you would need to update the library with more exceptions which is not that nice. Also, if we enumerate all objects which we should flatten and define how should we — it might be quite a big list. That was my first though when I started to dig in how flatten-like libraries work.

Thus I am wondering what is the typical use case for your library users ;)

P.S. The flatten for pure objects only turned to be just around 15 lines of code, so I switched to using it instead. Everything stated above is knowledge sharing.

from safe-flat.

I'm not opposed to this change, but I would like to see some support from the community before making it as it would be a breaking change.

from safe-flat.

from safe-flat.

My use case was Firestore Update which allows to update nested object using "dotted keys". Though it might have data types like Timestamps which doesn't need to get flatten.

from safe-flat.

I wonder if we do something like this, typeof <value>.constructor.name === Object makes sense? This will ignore date/primitives and cats as above.

from safe-flat.