Skip to content

Refactor and remove object utility functions #1811

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

Merged
merged 12 commits into from
Jun 27, 2019

Conversation

mmermerkaya
Copy link
Contributor

Used some newer JavaScript methods instead of custom implementations. Fixed types.

Also did the same things in packages that used the refactored object utility functions.

Copy link
Member

@Feiyang1 Feiyang1 left a comment

Choose a reason for hiding this comment

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

Thank you very much for taking it up! The more types the better! We will fix more places once we enable the global tslint checks.

I think we should also update @firebase/polyfills to include object.values and object.entries.

  1. It serves as a documentation for us
  2. I'd like to be able to point developers to this package and say these are the es2015+ features we use. They can manually include @firebase/polyfills if they don't want to or couldn't use Babel. We won't recommend it since we won't know what developers use in their own code, but I think it can be a nice option for people who is upgrading from v5 to v6.

@mmermerkaya
Copy link
Contributor Author

@Feiyang1 No problem! Also LMK if you need any help with the TSLint stuff.

Added those two to polyfills.

I think that the polyfills package is going to be difficult to keep in sync unless we change lib in the base TSConfig to es5 and then add the libs one by one, which would cause an error if we use a function that's not included there. It's not possible to add every single method independently, but there's ES2017.object at least. So we'd add that to lib in TSConfig and then import 'core-js/features/object'; to the polyfill package.

It's fine like this for now though. Just an idea.

Copy link
Contributor

@schmidt-sebastian schmidt-sebastian left a comment

Choose a reason for hiding this comment

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

I love cleanup PRs! Thanks for doing this. I wonder if we can reduce our usage of the utility functions more and left some comments. Let me know what you think!

@@ -41,44 +34,50 @@ export class ChildChangeAccumulator {
childKey !== '.priority',
'Only non-priority child changes can be tracked.'
);
const oldChange = safeGet(this.changeMap_, childKey) as Change;
const oldChange = this.changeMap.get(childKey);
Copy link
Contributor

Choose a reason for hiding this comment

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

@mikelehen Do you know if there is a reason for safeGet()?. Are we guarding against queries for length or something similar?

Copy link
Contributor Author

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 guarding against accidentally getting a value from the prototype chain.

@googlebot
Copy link

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of all the commit author(s), set the cla label to yes (if enabled on your project), and then merge this pull request when appropriate.

ℹ️ Googlers: Go here for more info.

@wilhuff wilhuff force-pushed the mmermerkaya-refactor-obj branch from eed06e8 to 407a59a Compare May 25, 2019 01:15
@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@schmidt-sebastian schmidt-sebastian removed their assignment May 31, 2019
@Feiyang1
Copy link
Member

@mmermerkaya What is the state of the PR? any blocker?

@mmermerkaya mmermerkaya force-pushed the mmermerkaya-refactor-obj branch from 69c6876 to 0c4594a Compare June 24, 2019 15:08
@mmermerkaya mmermerkaya changed the title Refactor object utility functions Refactor and remove object utility functions Jun 24, 2019
Copy link
Contributor

@schmidt-sebastian schmidt-sebastian left a comment

Choose a reason for hiding this comment

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

I like the simplification a lot, but I do think that we should be careful about using the Object.keys/Object.values functions as they create copies of data. There are some parts of this PR where I would really advocate we don't do that (ImmutableTree for example), but in general I think it will be better if we directly iterate everywhere without using these helpers.

I flagged some usages here, some of them may be insignificant. I also left some out where I think we don't need to bother (like the StatsCollector).

@mmermerkaya mmermerkaya force-pushed the mmermerkaya-refactor-obj branch from 17f9aa3 to 1ab4ad0 Compare June 25, 2019 14:40
@mmermerkaya
Copy link
Contributor Author

Reverted (almost) all changes that added Object.* calls in Database. Replaced the forEach function from @firebase/util with DB's own util function each.

FWIW, the need to iterate over plain JS objects looks like a code smell to me. I'd recommend using ES6 Maps over objects if the keys aren't known in compile time and/or can change.

Copy link
Contributor

@schmidt-sebastian schmidt-sebastian left a comment

Choose a reason for hiding this comment

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

LGTM. I do want to ask @Feiyang1 about the Polyfills though, so please hold off on merging.

@schmidt-sebastian schmidt-sebastian removed their assignment Jun 25, 2019
@mmermerkaya mmermerkaya force-pushed the mmermerkaya-refactor-obj branch from d2ec322 to 082b90d Compare June 26, 2019 17:52
Copy link
Member

@Feiyang1 Feiyang1 left a comment

Choose a reason for hiding this comment

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

Just 1 question and a pending PR #1922

* cherry pick es2015+ libs

* remove lib flag from installations
@mmermerkaya mmermerkaya merged commit 857b0fe into master Jun 27, 2019
@mmermerkaya mmermerkaya deleted the mmermerkaya-refactor-obj branch June 27, 2019 19:16
@firebase firebase locked and limited conversation to collaborators Oct 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants