30-seconds-of-code: alternative getType

Created on 3 Oct 2018  路  8Comments  路  Source: 30-seconds/30-seconds-of-code

Description


Just want to know can the snippet below be the alternative of the implement of getType function

const getType = v => Object.prototype.toString.call(v).slice(8, -1).toLowerCase();
discussion

Most helpful comment

This is an adaption of the code that Array.isArray() polyfills use.

My personal preference is to use a split on space before the slice so that we don't run into any odd issues if it's not [object Something].

const getType = v => Object.prototype.toString.call(v).split(' ')[1].slice(0, -1).toLowerCase();

We'd have to check for edge cases between the two before a replacement, but none that I can think of are coming to mind. We may just want to PR a test suite that tests every type for the expected values and compare the two implementations. From what I can see there should be no difference. I do however wonder what issues changing prototypes can cause and how it'd impact either implementation.

The biggest merits on either implementation though are readability and maintainability. We should vote on what merits we'd like for this snippet to have if we're going to replace it.

So first a reaction vote:

  • Thumbs Up: vote to investigate replacement
  • Thumbs Down: vote to keep current implementation

All 8 comments

This is an adaption of the code that Array.isArray() polyfills use.

My personal preference is to use a split on space before the slice so that we don't run into any odd issues if it's not [object Something].

const getType = v => Object.prototype.toString.call(v).split(' ')[1].slice(0, -1).toLowerCase();

We'd have to check for edge cases between the two before a replacement, but none that I can think of are coming to mind. We may just want to PR a test suite that tests every type for the expected values and compare the two implementations. From what I can see there should be no difference. I do however wonder what issues changing prototypes can cause and how it'd impact either implementation.

The biggest merits on either implementation though are readability and maintainability. We should vote on what merits we'd like for this snippet to have if we're going to replace it.

So first a reaction vote:

  • Thumbs Up: vote to investigate replacement
  • Thumbs Down: vote to keep current implementation

The current implementation is pretty great, so I don't mean to replace it.
Just wonder the difference of details between those two implements.馃檪

The difference comes down to how the engine finds the prototype/class of the object. One does by property climbing, the other does by constructor naming. Both have possible issues, but to know those will require a deeper dive into JS to discover than I think most of the devs here have done just yet.

Based on the fact that classes (and, in extension, constructors) are a thin layer on top of prototypes, I would prefer investigating this deeper and seeing if the prototypical approach proposed in this issue works the same or better than our current implementation. It might be slightly more verbose, but I think it has less potential for errors.

I've wondered the differences between:

value.constructor === Array

and

({}).toString.call(value) === '[object Array]'

I think the implementation suggested above works just as well as the current one and is a decent replacement.

const getType = v => Object.prototype.toString.call(v).split(' ')[1].slice(0, -1).toLowerCase();

However, I'm voting to keep the one we have as it is easier to read and understand for newcomers, especially when they come from an OOP language and want to do type-checking (which is pretty standard in that scenario).

Based on the fact that this has been inactive for two months now and nobody has submitted a PR, I'm gonna close for now. If anyone wants to investigate, please comment below or open a PR and we can start there.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for any follow-up tasks.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Chalarangelo picture Chalarangelo  路  5Comments

fplgusmao picture fplgusmao  路  4Comments

fejes713 picture fejes713  路  4Comments

emelendez picture emelendez  路  4Comments

fuchao2012 picture fuchao2012  路  4Comments