Add a strip function to remove non-critical moment properties

[ichernev]

We've been adding properties to the moment object here and there and now most of them are used only at the parsing stage, revealing information about what exactly got parsed and how, but most users don't care and if you happen to have a big array of objects this also leads to higher memory footprint.

So lets add a function moment.fn.strip(), that would remove all unnecessary properties, and keep only: _isAMomentObject, _isUTC, _l, _d. _offset.

[icambron]

Instead of strip, I think it should just be an option at creation time. "lean" or somesuch. My thinking is:

• We should keep the mutable surface area as small as possible.
• Creating and then removing it means it has to wait for the GC to come get it

Also worth noting: the expensiveness of parsingFlags only comes up when you actually parse a lot strings; cloning just copies the reference (shallow clone, which is totally right).

[timrwood]

Another use case to keep in mind, moment-timezone uses the _a and _tzm properties to check if it an offset was included in the input string.

https://github.com/moment/moment-timezone/blob/9fc647a10b9efa5566b46442e0b5b6abe5d8eeb9/moment-timezone.js#L285

[icambron]

Ah, that's a good point. It also puts a big hole in my idea in #1754 to just make clone explicitly copy the fields (which might be a good optimization for clone whether or not we do immutability); we don't know what fields defined in plugins need to be copied.

[ichernev]

In the latest version there is a way for plugins to add the fields they're adding to moment to the whitelist. Latest moment-timezone is doing that. Just edit moment.momentProperties.

The thing is I broke moment-timezone for a bit and nobody noticed. I wonder how many other plugins are broken. We can copy fields beginning with underscore for now and warn for each field separately -- hopefully more people would see / report those back to us, and then we'll pinpoint the offensive plugin.

[icambron]

@ichernev Oh cool, that gives me a path back to my optimization idea. I can just remove items from momentProperties (i.e. before there are plugins, it's just empty), assign them explicitly, and then only iterate through the momentProperties if there's anything in it.

Re: breaking plugins: we can just look through the ones on the docs and see if they fiddle with the moment object directly. I suspect most don't, since they're mostly about building, wrapping, or formatting moments, not altering their behavior like TZ does.

[ichernev]

I didn't quite get the optimization thing.

[icambron]

Sorry, referencing other tickets. I'll explain with code and some perf tests.

[maggiepint]

So, two years later now, I think there is quite a bit of code that relies on parsing flags and other variables being the way they are, and this change doesn't make sense. As such, I'm going to close this for the sake of cleaning house on issues. I'll assign a v3 milestone in case we want to find it down the road when considering total rewrite style scenarios.