To do

In addition to what's described in future directions, there are some things that we'd like to add to the library:

@angular-react/core

• Explore the option of replacing the usage of styles (with 'react-renderer') with data, which seems more appropriate for this sort of thing.

  • The issue with this is that the ReactRenderer is currently a singleton, meaning that the data is shared across all components, regardless of the component being rendered.
  • If this is not possible, at least export 'react-renderer' as a const and import it as needed in wrapper components, if possible (the Angular compiler may complain, at least in AOT compilation).

• Explore using React Portals instead of regular ReactDOM.render() for every wrapper React component.

  As described in limitations, currently each component instance is isolated in its own React VDOM tree. Meaning that things that aren't explicitly passed down between components are not shared (like Context).

  There is a good claim to be made that only a root element should be rendered using ReactDOM.render(), and then subsequent ones using ReactDOM.createPortal(), to allow Context etc. to be accessible from all React elements in the tree. Using React Portals introduces some complexity (like event bubbling), but we thing it may be worth it, as either an opt-in, or an opt-out feature, per component.

  There is no technical limitation blocking this, and we are open for community feedback and contributions on this as well.

• Explore the option of creating a simple generic wrapper components, similar in nature to what projects like react2angular offer (but for Angular 2+), to allow easier usage of React components within Angular. These components would not enjoy the benefit of having a more Angular-y API when exposed to apps, but may be sufficient for some use-cases. See #103 for more details and follow up.

@angular-react/fabric

• Add more wrapper components for components in office-ui-fabric-react
• Create more declarative patterns where applicable (#3)