Skip to content

refactor(database): Add typescript database implementation [Part 2/3] #62

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 11 commits into from
Jun 28, 2017

Conversation

jshcrowthe
Copy link
Contributor

Adds the new typescript implementation

@jshcrowthe jshcrowthe changed the title refactor(database): Add typescript database implementation [Part 2/4] refactor(database): Add typescript database implementation [Part 2/3] Jun 16, 2017
@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 by someone other than the pull request submitter. We need to confirm that they're okay 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 the commit author(s) and merge this pull request when appropriate.

@jshcrowthe
Copy link
Contributor Author

@schmidt-sebastian It seems CLA bot doesn't like squash commits. This is fine to review/merge as you're able.

@jshcrowthe
Copy link
Contributor Author

This PR presumes that #61 has been merged first

@jshcrowthe jshcrowthe force-pushed the ts-database/add-new-impl branch from 7efa1b0 to 2f6a406 Compare June 20, 2017 22:26
@jshcrowthe
Copy link
Contributor Author

@schmidt-sebastian this has been rebased so it only includes the additions.

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.

Hi Josh, I think most of my comments are going to be similar to the ones I have in the first couple of files I reviewed. Can you take a quick look?

}

get key() {
return this.getKey();
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it make sense to make this the main codepath and call this from getKey()

/**
* Returns whether the snapshot contains a non-null value.
*
* @return {boolean} Whether the snapshot contains a non-null value, or is empty.
Copy link
Contributor

Choose a reason for hiding this comment

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

As discussed over chat, we should figure out if we want to keep the type annotations in our comment or if it is sufficient to use the types from TypeScript.

Copy link
Contributor

Choose a reason for hiding this comment

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

Just chiming in since I was thinking about this the other day. Type annotations in the comments only make sense when using a tool like Closure compiler to do type checking, but it's not necessary anymore with TypeScript. Besides, I bet the types in the comments won't always be updated when the code changes so eventually it might do more harm than good.

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'm happy w/ defaulting to typescripts types. Just was trying to keep the delta small where possible.

That said, I think I'm going to merge #66 as I've been going through that and it addresses many of the type issues you've mentioned.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In addition I agree with @jsayol, that the divergence in types is probably a maintenance burden going forward. Let's consolidate after we've validated the code is good.

*/
export class Database {
/** @type {Repo} */
repo_;
Copy link
Contributor

Choose a reason for hiding this comment

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

I assume this can just use the typescript types (aka repo_: Repo)?

Copy link
Contributor

Choose a reason for hiding this comment

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

FYI there's another PR (#66) that builds on top of this one adding a whole bunch of types, const/let, private, etc.

Copy link
Contributor Author

@jshcrowthe jshcrowthe Jun 27, 2017

Choose a reason for hiding this comment

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

I'll try and get @jsayol's PR merged as part of this.

EDIT: The PR mentioned has some tests that fail. I will work on consuming that afterwards.

fatal("Don't call new Database() directly - please use firebase.database().");
}

/** @type {Repo} */
Copy link
Contributor

Choose a reason for hiding this comment

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

This type information should now be unnecessary.

this.INTERNAL = new DatabaseInternals(this);
}

app: null
Copy link
Contributor

Choose a reason for hiding this comment

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

Add type information.

* @param {string=} opt_pathString
* @return {!Firebase} Firebase reference.
*/
ref(opt_pathString): Reference {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use 'pathString?: string' here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yup

*/
refFromURL(url) {
/** @const {string} */
var apiName = 'database.refFromURL';
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be 'const' instead of var.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Deferring to #66


/**
* @param {string} apiName
* @private
Copy link
Contributor

Choose a reason for hiding this comment

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

Please use 'private checkDeleted_()" instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

K

};

// Note: This is an un-minfied property of the Database only.
Object.defineProperty(Database.prototype, 'app', {
Copy link
Contributor

Choose a reason for hiding this comment

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

Here and below: Can this be a getter in the main class?

return this.repo_.app;
}

get database(): Database {
Copy link
Contributor

Choose a reason for hiding this comment

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

The database getter actually belongs in Repo

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great catch! Thank you!

* @param {(function(!DataSnapshot, ?string=))=} callback
* @param {Object=} context
*/
off(eventType?: string, callback?: (a: DataSnapshot, b?: string | null) => any, context?: Object) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we introduce a type declaration for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

}

// Calling with no params tells us to start at the beginning.
if (value == null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

the original code uses undefined

Copy link
Contributor

Choose a reason for hiding this comment

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

There's a parameter initializer on value (= null) so by the time it reaches this check it will never be undefined.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

* @param {boolean} committed
* @param {fb.api.DataSnapshot} snapshot
*/
constructor(committed, snapshot) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you let TS do the member assignment here directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@jshcrowthe jshcrowthe force-pushed the ts-database/add-new-impl branch from f108014 to 61c8d25 Compare June 28, 2017 22:43
* @param {function(?Error)=} opt_onComplete
* @return {!firebase.Promise}
*/
cancel(opt_onComplete) {
Copy link
Contributor

@schmidt-sebastian schmidt-sebastian Jun 28, 2017

Choose a reason for hiding this comment

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

Here and everywhere - type should be: onComplete?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done (I also did it for all the declarations below)

@schmidt-sebastian
Copy link
Contributor

As discussed over Hangouts, this is good to merge. I went through the first 25+ files in detail and most of the issues I encountered are getting addressed in subsequent PRs (and all of them are just to make the codebase more TS-like). The tests are also passing at this point and we should merge this into the TS branch.

@jshcrowthe jshcrowthe merged commit bb80d31 into ts-database/final Jun 28, 2017
@jshcrowthe jshcrowthe deleted the ts-database/add-new-impl branch June 28, 2017 23:03
jshcrowthe added a commit that referenced this pull request Jul 6, 2017
* refactor(database): remove old database implementation [Part 1/3] (#61)

* refactor(database): remove old database implementation

This is part #1 of 4 PR's to migrate database

* refactor(database): remove database build processes

* refactor(database): Add typescript database implementation [Part 2/3] (#62)

* refactor(database): add typescript implementation

* refactor(database): update build process to include database.ts

All integration tests pass at this point

* refactor(*): refactor environment builds to be based on separate .ts files

* WIP: patch database code in nodeJS

* refactor(database): classes for typescript database implementation (#55)

* refactor(database): classes for typescript database implementation

* refactor(database): requested changes & other improvements

* fix(database): Add missing "typeof" (#74)

https://github.com/firebase/firebase-js-sdk/blob/fd0728138d88c454f8e38a78f35d831d6365070c/src/database/js-client/core/Repo.js#L86

* WIP: fixes from @schmidt-sebastian's review

* WIP: fix: TS Build error

* fix(database): fix issue with missing repo method

* WIP: review adjustments #1

* WIP: review comments #2

* WIP: refactor(database): Add migrated test harness [Part 3/3] (#71)

* refactor(database): add typescript implementation

* refactor(database): update build process to include database.ts

All integration tests pass at this point

* refactor(*): refactor environment builds to be based on separate .ts files

* WIP: patch database code in nodeJS

* refactor(database): classes for typescript database implementation (#55)

* refactor(database): classes for typescript database implementation

* refactor(database): requested changes & other improvements

* WIP: add the /tests/config dir to the .gitignore

* WIP: add test harness

* WIP: add query tests

There are some tests that have weird timing issues, and because of the polling nature of the
original implementation, we never caught the issue. These should be resolved when able

* WIP: add database.test.ts

* WIP: add node.test.ts

* WIP: add sortedmap.test.ts

* WIP: add datasnapshot.test.ts

* WIP: add sparsesnapshottree.test.ts

* refactor(database): refactor query.test.ts to better preserve original test meaning

* WIP: add crawler_support.test.ts

* WIP: refactor EventAccumulator.ts for data.test.ts

* WIP: fix issue with query.test.ts

* WIP: add connection.test.ts

* WIP: add info.test.ts

* WIP: add order_by.test.ts

I only migrated some of these tests as there was a dependency on the server for several tests

* WIP: fix several code signature problems, add test files

* WIP: add transaction.test.ts

* WIP: working on the broken npm test command

* WIP: working on fixes

* WIP: remove logging

* WIP: fix node tests

* fix(*): fixing test files and CI integration

* WIP: tEMP: Allow branch builds

* WIP: escape string

* refactor(CI): use ChromeHeadless launcher

* WIP: fixes from review.

* WIP: skip flakey test

* WIP: remove unneeded debugger statement

* WIP: fixing nits

* Prevent using uninitialized array in EventEmitter (#85)

* perf(*): fixing build size output issues

* chore(*): remove unneeded build deps
@firebase firebase locked and limited conversation to collaborators Oct 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants