Refactor FilesAdapter to ES6 style.

[nlutsenko]

Class-based, nice import style and friends, also removed duplicate logic.
cc @drew-gross

[peterdotjs]

@nlutsenko we can also start replacing var with let and const as we're refactoring to es6.

[gnz00]

I refactored the whole repo here: https://github.com/maysale01/parse-server/tree/es6-all-tests-passing

[gnz00]

Can re-use some of that, it's been like ~60 commits. All tests were passing as of HEAD-2 commits or so, I started to make everything async and abstracted the cache and have 1 or 2 tests not passing.

[nlutsenko]

Yeah, good call. The biggest point here is to create classes for pluggable modules - like Files or Database, but agree that we should probably do let/const instead of var.

[nlutsenko]

Updated with let/const, slightly cleaner export/import syntax for GridStoreAdapter.

[facebook-github-bot]

@nlutsenko updated the pull request.

[peterdotjs]

@maysale01 We definitely appreciate you making the es6 fork. The current plan is to es6ify files as we touch them moving forward.

[gnz00]

@peterdotjs Yeah it's too far gone at this point anyways. Might be a good reference point, or just to copy some boilerplate. It's 1-1 for the most part.

[drew-gross]

I don't really like this setAdapter function. Being able to change adapters while the server is running seems like a recipe for disaster. What happens to in-progress async actions? Can remove the setAdapter function?

[nlutsenko]

@drew-gross What did you have in mind?
I can store the FilesAdapter on the server itself, but the previous implementation already had a global setAdapter, so ideas welcome here... Also might be a part of a separate PR.

[peterdotjs]

@drew-gross since we're only using setAdapter during initialization would it be worth policing for incorrect usage? We could add a lock to prevent changes after ParseServer is initialized.

[drew-gross]

I would prefer the configuration accept 3 different options: 1) a instance of an object that meets the FilesAdapter interface 2) the name of an npm module that will be required along with an options object that will be used to initialize (this is to allow pure json config) or 3) a class and the same options object.

Rather than having the function exist and trying to police the PRs to make it never gets called inappropriately, we should just remove it and guarantee it's never called inappropriately :p

See more discussion in #275 and #290

[flovilmart]

@drew-gross I second that, and that could be extended for all adapters as discussed around #290

[gnz00]

This is implemented per our discussion in #291. Needs to be reviewed

[flovilmart]

@maysale01 i can review now