Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace lodash utils #131

Merged
merged 6 commits into from
Jun 18, 2015
Merged

Replace lodash utils #131

merged 6 commits into from
Jun 18, 2015

Conversation

frankychung
Copy link
Contributor

From #112 -- Removing lodash utils decreases the build size significantly as described by @dariocravero so this PR replaces the remaining three lodash modules with basic utils.

@@ -0,0 +1,3 @@
export default function identity(value) {
return value;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually lodash's identity function is the same as yours but yes this does make sense to totally remove lodash as dependancy if this will be only one function needed from it

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably best to put these all in a single file and export them individually that way you avoid the overhead of including each file, I think it adds ~3 lines and a bunch of bytes for every file you include.

This also has the benefit of keeping all the utils together.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an aside: identity would then be something like:

export const identity = x => x; which is just 😎

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@goatslacker Grouping these in one file sounds like a good idea to me however I worry it doesn't follow the style of the rest of utils of exporting one function per module (or as @taylorhakes mentions inlining some of them, especially simple ones like identity). Also, exporting arrow functions is pleasantly succinct but also another question of style :). @gaearon thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As @goatslacker suggested, using an arrow function would be better because:

  • identity is not new-able
  • identity has no prototype

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably best to put these all in a single file and export them individually

👍

using an arrow function would be better

I think it's just a matter whether we want to have it as a named function or not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's just a matter whether we want to have it as a named function or not.

It is not the only implication of arrow functions 😉

Just returning the argument so can check by reference instead of deep
equal
@taylorhakes
Copy link
Contributor

These functions are only used in one spot each. I think it would be better to keep the code inline and not create an unnecessary abstraction in another file. If they start to get used a lot or become a source of bugs, then put them in another file.

@@ -0,0 +1,3 @@
export default function isPlainObject(obj) {
return typeof obj === 'object' && Object.getPrototypeOf(obj) === Object.prototype;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one does not work.

isPlainObject(null) // TypeError: Object.getPrototypeOf called on non-object

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, added another test case for calling with null

@@ -0,0 +1,3 @@
export default function isPlainObject(obj) {
return obj ? typeof obj === 'object' && Object.getPrototypeOf(obj) === Object.prototype : false;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A simple way to detect a pojo is to do Object.prototype.toString.call(object) === '[object Object]' or something like that

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I won't work:

var F = (function(){})
var f = new F
Object.prototype.toString.call(f) // [object Object]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ooflorent Are we trying to avoid the object above or Object.create(null)? It is perfectly fine for someone to have a React state that is not a plain object. ImmutableJS is used for state and it is not a plain object.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is perfectly fine for someone to have a React state that is not a plain object.

I thought that broke in some recent version, didn't it? Either way they don't officially support it yet.
facebook/react#3303

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I want from isPlainObject:

  • no to arrays
  • no to null or undefined
  • no to ImmutableJS records (or other things that have a prototype)

I don't really care for edge cases like Object.create(null).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gaearon I retract my earlier comment. You are correct

gaearon added a commit that referenced this pull request Jun 18, 2015
@gaearon gaearon merged commit 94b6a48 into reduxjs:master Jun 18, 2015
@gaearon
Copy link
Contributor

gaearon commented Jun 18, 2015

This looks good to me. I want to go ahead with #112 so merging.
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants