Replies: 1 comment
-
|
@lemonmade My "host" application is built using React Native. I'm trying to understand whether I should be utilizing |
Beta Was this translation helpful? Give feedback.
-
|
@lemonmade My "host" application is built using React Native. I'm trying to understand whether I should be utilizing |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
History
When I originally wrote remote-ui, I was most heavily inspired by
react-reconciler, the package that allows developers to transform React’s “virtual DOM” into any number of natively rendered targets. I felt it was critical to choose a model that maintained a “pure” JavaScript representation of a tree of UI components, and allowed that representation to be translated before finally being rendered in the host application.@remote-ui/corewas the result of this design.react-reconcilerand@remote-ui/coreboth look awfully familiar to anyone who has done web development. That’s because they both lean heavily on another JavaScript representation of a tree of UI components many of us are familiar with — the DOM. Though I added more DOM-like APIs to remote-ui over time, remote-ui is totally independent of the DOM today. I avoided the DOM for two main reasons:Since I wrote the first version of remote-ui, I have seen changes in the web development ecosystem that have made me second-guess my original design:
@remote-ui/core, but not all frameworks do. In contrast, all web frameworks provide first-class support for binding to the DOM. Even in packages that do support custom renderers, the provided APIs have often been unstable and difficult for other developers to contribute on. As a result, remote-ui’s integrations with frameworks have been maintained fairly poorly, especially for Vue, which I do not personally use on a regular basis.Today
Today, I’m happy to re-release remote-ui under a new name: Remote DOM. The name change is more than a coat of paint — the entire repo has been rewritten to be powered entirely by the DOM. “Remote component” are now just custom elements that you can render in the “remote” DOM environment, and any library built to work with the DOM now works without any special adaptors. We’ve also written a small DOM polyfill, so you can continue to run sandboxed code in Web Workers and other environments without a native DOM. Many thanks to @developit for the inspiration to pursue this approach, and for his initial implementation of the DOM polyfill.
If you’re new to remote-ui and Remote DOM, we believe this DOM-based library will make it much easier to get started, and opens up a wider range of libraries for use in your “remote” application code. We’ve prepared a collection of new examples that shows how to create both the “host” and ”remote” environments Remote DOM expects. Once you’ve understood these basic examples, the
@remote-dom/corepackage contains documentation for most of the key features of the library.If you have an existing setup using remote-ui, the migration will be a bit more involved. We’ve prepared a detailed migration guide to help you understand the new equivalents of older APIs. The latest remote-ui source code is available on the
remote-uibranch of this repo, and the@remote-ui/rpcpackage remains supported and un-deprecated, since it was not tied to the way the UI elements are represented.If you have any questions about the transition, please post them below.
Beta Was this translation helpful? Give feedback.
All reactions