I.e., use list and member initializer syntax where possible.

Unit tests are failing when they are compiled with .NET Native. The error is coming from Chakra. For now, the unit test project is not compiled with .NET Native.

Currently, we push the callback onto the thread pool, but this requires awaiting. We may want to require the user to specify where they want the callback to occur.

Handling things like screen bound changes.

Event emitter hooks into keystroke event changes.

We've recently found that you can use UITestMethod to have the test run on the Dispatcher thread, instead of capturing the dispatcher during app initialization and hijacking through the DispatcherHelpers.

This should also allow us to remove the InternalsVisibleTo declaration in Properties.cs

Ensure that ReactMethods return void (or else throw).

Investigate what react-native-cli does for other projects and replicate for UWP.

Abstract the parts of the React Native library that do not directly touch UWP components into a portable library. This will allow us greater agility in the future to move to new frameworks (e.g., Xamarin), or support older ones (e.g., Windows 8).

The React Native protocol supports batching of operations between native and JavaScript. Implement a good strategy for managing (queueing, invoking, etc.) batch requests.

In addition to supporting a promise data type in the ReactMethods, we should also add support for invoking asynchronous methods and chaining the result to a promise. This needs to be managed very carefully, as the native modules are run using the "AnyBackgroundThread" spec; the concern is that if the asynchronous call releases control too early, it may allow the next item in the native queue to execute.

Currently, we have the ICallback interface that allows users to respond to JavaScript with callback hooks. We also need support for promises.

Currently, callbacks can only be bound to the ICallback interface. We should support arbitrary delegates, just for fun.

We should confirm that compiling a delegate to invoke ReactMethods will actually pay off. We may want to consider having an alternative base class (or a flags enum for options) that can switch on or off the ability to compile a delegate or use reflection.

Write an analyzer that ships with the ReactWindows NuGet package that will give compile time checks for things like function name overloads.

Include features like:

• template for creating a React Windows app
• template for creating React modules

This includes sealing classes as appropriate, and making anything that does not need to be public internal.

This should include things like exception handling, debugging, etc.