Deprecate Existence Utils

[elwayman02]

I've been thinking a lot this week about the existence utils in @ember/utils (e.g. isEmpty, isBlank, isPresent, isNone), and I'm thinking it might be a good idea to deprecate them. There's a lot of confusion around what they do, and as a result any implementation that uses them is tied heavily to specific behavior that is non-intuitive and adds unnecessary cognitive load for developers trying to understand code using these utils. Additionally, libraries like lodash already have methods like isEmpty, isObject, isObjectLike, isNull, and isUndefined that cover a similar surface area, and we could add to a project like that if there was a specific utility we find somewhat valuable to keep as a community.

A few colleagues I spoke with about this already had some thoughts which I'm including in full below:

• isEmpty({}) returning false is non-intuitive (and IMO wrong). An “empty” object would be one that has no entries like an “empty” array has no elements or an “empty” string has no characters.
• using isEmpty or isBlank should be sugar for checking things like str === undefined || str === null || str === '', but where that fails is that javascript is not statically typed. Exported functions can be called in any context, so they have to account for all different types and their definitions of empty/blank/etc. Other languages don’t have these problems because String.isEmpty is different than Array.isEmpty and calling String.isEmpty([]) is a compiler error.
• In general I think I’d avoid using the ember existence utilities since you have to know what they do and know what you are doing and the person coming after you needs that same knowledge. just doing thing && Object.keys(thing).length >0 or something similar is immediately “grokable” even by someone without ember experience. although slightly more verbose, I feel using the ember utils are always more confusing than just using vanilla as much as possible.

A few questions for people to ponder and respond to:

• Do you use these utils heavily, or have you moved away from them?
• What value, if any, do you see these utils having over using vanilla JS checks?
• What issues, if any, have you seen arise from using these utils?
• What barriers do you foresee in deprecating these utils? How heavily are they used in Ember internal code?

[jherdman]

Do you use these utils heavily, or have you moved away from them?

I definitely use them, but primarily because e-auto-import wasn't a thing when I started writing Ember code. These days I'd still use them provided that they're available and not deprecated, solely because I don't want to add more bytes to my code.

[elwayman02]

@jherdman if you were getting these utils from a library like lodash, where you can import individual utilities as modules instead of having to bundle the entire library into your app, would that be sufficient for you, particularly if the goal of said deprecation was to eventually remove the methods (and the bytes they take up) from Ember core?

[jherdman]

Definitely.

[jackson-dean]

In a larger code base with new developers regularly onboarding/leaving, these utils can be an ongoing source of confusion and incorrect use. And there are so many of them with their own specific nuance (isEmpty vs isBlank vs isNone, etc). It does not seem very explicit what the intention is when I see these used. Did the person know exactly what they wanted and know exactly what they're doing, or did he/she copy/pasta from somewhere else with an assumption (possibly incorrect) about the behavior? It is very hard to say without some back and forth and a refresher for myself about what they do. Just my personal preference, but in an environment like that it is almost always better for maintenance and future readability to use a check with native js that expresses the exact intention. I would personally favor deprecating them.

[lougreenwood]

I've never used them and I've actively avoided them.

I started using Ember around 3.0 release and I've always seen these as a part of the "old" Ember architecture which aimed to provide for every possible eventuality.

IMO - Ember is a UI framework and checking existence of values should not be part of the public concerns of a UI framework.

[mcfiredrill]

isEmpty({}) returning false is non-intuitive (and IMO wrong). An “empty” object would be one that has no entries like an “empty” array has no elements or an “empty” string has no characters.

Are you referring to this?

Ember.isEmpty({})
false

This does seem strange...

Do you use these utils heavily, or have you moved away from them?

Our app began in 1.11.x era and is currently on 3.10. We started using lodash early on and have avoided these helpers.

What value, if any, do you see these utils having over using vanilla JS checks?

I see value to not repeating implementations of given checks across your codebase. That, however, seems like a problem best left to application authors.

For any concerns deprecating usage we could use ember observer's code search and ask for community feedback. I think codemods could solve a number of those cases if there is demand.

[noyesa]

I use it because isEmpty(maybeArray) is shorter than !maybeArray || maybeArray.length === 0.

In most cases the question I'm asking is "is this a usable value for me" so I don't really care if it's null, undefined, or an empty array -- all three values mean the same thing to me, namely to do nothing with it.

underscore or lodash can also accomplish this so I don't really care which one I use.

[thousand]

Like noyesa, i like the DRYness, but i end up looking at these utils' truth tables somewhat regularly to make sure they're doing what i expect. If they disappeared from ember, i would just use vanilla logic (or write my own abstractions when that's gnarly) rather than pulling in another dependency like lodash. Ember addons/apps have a lot of dependencies already and while lodash and underscore are handy libs that i've used quite a lot, i'd just rather not deal with yet another lib to keep up to date.

[willviles]

I’m in the “nuke the all” camp. I think for the future success of Ember, vastly reducing the surface API is of upmost importance. Ember should be seen to interface with popular packages (such as lodash) at every opportunity, rather than offering Ember-specific implementations, each with their own little quirks.

For backwards compatibility, who’s saying @ember/utils can’t be an addon which can be explicitly installed to continue using the utilities and remove deprecation warnings from modern apps?

[corrspt]

I use them regularly, but I guess it's just convenience because they're there (and I mostly only use isEmpty).
I don't mind them going away, but I would like either a codemod to migrate them to something else, or an addon to keep compatibility (but preferably a codemod, even if I have to install lodash)

[snewcomer]

#334

Here is an rfc I wrote a while back. I agree with what was said in the description. One thing that comes up quite often, say in code reviews is just using plain old JS. These utils, while useful, may increase the cognitive load bc it applies to all types when, in reality, you only need to check a String for example. Also, which one do you use? It is this cognitive load that may trip ppl up. On the other hand, they can be simply included in parts of your codebase and you know it works.

I like the idea of a codemod, but there are lots of specific scenarios you may want the util bc we don't know the type of variable that gets passed to the util function.

[wagenet]

The associated RFC has been merged!