Previously we were not accounting for the byte offsets and misunderstood how the Uint8Array constructor worked. The tests now confirm everything works as expected with multiple different typed arrays and slices of the data.
React Native now leaves the original object accessible when it "polyfills" objects. So we check for that, but still have the previous logic in place in case they change their minds.
Rather than using Object.preventExtensions to throw exceptions when setting any out-of-bounds index, we must instead compromise by only throwing for the common cases, which are -1 and list.length. Having Object.keys() support is essential for List to work with React Native ListViewDataSource.
Resolves#80
Added a session ID, that actually tracks the Realm constructor in our RPC server's JS context. This conveniently let us remove the special casing for defaultPath as well as letting us call the Realm constructor with JSObjectCallAsConstructor.
Fixes#68
Since notifications are called synchronously after a write, we fake it by calling them manually for now. The future plan will be more involved, so some of that is stubbed out.
The deleteTestFiles() function is now added to the Realm object, so that it's easy for the RPC module to handle this as well. We can only do this in testing environments in the future.
An exception was thrown when parsing the JSON when only a string was passed. This is better and no longer uses the Objective-C API for converting the dictionary to a JSValue.
The idea is that we will have an NPM module that should always be required to use the Realm JS API. It will handle the underlying implementation details depending on which environment it is being run in (i.e. JavaScriptCore, Chrome, Node).
The focus here was on stubbing out the machinery required to get React Native Chrome debugging working with the Realm API by leveraging synchronous requests. The app itself will need to run a web server that responds to these requests.
Ari Lazier
Scott Kyle