ReactXP – A library for building cross-platform apps(microsoft.github.io) |
ReactXP – A library for building cross-platform apps(microsoft.github.io) |
Be very careful when an OS vendor makes a move like this.
> The Skype team initially adopted the Flux principles, but we found it to be cumbersome. It requires the introduction of a bunch of new classes (dispatchers, action creators, and dispatch events), and program flow becomes difficult to follow and debug. Over time, we abandoned Flux and created a simpler model for stores. It leverages a new language feature in TypeScript (annotations) to automatically create subscriptions between components and stores. This eliminates most of the code involved in subscribing and unsubscribing. This pattern, which we refer to as ReSub, is independent of ReactXP, but they work well together.
That's interesting, I wonder how this differ from redux and others
I wonder also how is navigation is handled, is it easy to add react navigation in the mix?
Clicking on Next while on https://microsoft.github.io/reactxp/docs/animations navigates to a 404
I find error-handling to be particularly awkward in the Flux flow. You've got the option of adding in callbacks (goodbye unidirectional data flow) or storing errors in global state which makes tracking down errors properly a right pain. Do you have to generate a nonce for every action that could fail and look for that in errors later? That isn't particularly reactive. Are you making data types polymorphic so they're either the thing I actually want or some error class? That doesn't mesh well with collection objects and is kind of gross in general.
I've had trouble finding/figuring out a clean solution for error handling. The flux patterns I've seen feel lacking with regards to error ergonomics.
Looks similar to rxjs or mobx based state stores.
These days I use virtual DOM for performance but the architecture hasn't changed in years. The observable pattern with viewmodels is very efficient.
Looks like someone rediscovered/reinvented dataflow constraints, in a slightly hacky way.
See also: The Siren Call of KVO and (Cocoa) Bindings (http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...)
At first glance I decided not to read the article because I thought it irrelevant due to the XP.
Don't worry, most of the target audience of devs wasn't even 10 when Windows XP was a thing that mattered...
XAML is an abandoned platform. I've been with WPF for maybe 8 years. Haven't enjoyed coding like i do now. If you have ever worked with React, it will change you. It is something else to be able to make a UI with ease, to be absolutely confident about state, and to tap into the biggest community on earth (npm) to import whatever you want. Also tooling, the ability to edit modules live while the rest of the application just stays put.
React Native already supports iOS, Android, and UWP. To add browser support all you need is something like React Native for Web. I made a small presentation a few months ago that shows this. Here's the source code: [2]. Take a look at the web folder.
Libraries like React Navigation [3] have also been built to support any platform that runs React code. It looks like Microsoft built yet another navigation library [4].
Also, check out React Primitives [5]. It aims to define a set of primitives that work on any platform that can be used to build more complex components. This is highly experimental, but I'm liking the direction where it's going, a unified React interface for any platform.
In addition, ReactVR is a great example of how React Native primitives can be extended to new emerging platforms [6].
Finally, React Native for macOS [7] answers the question that many have here about building native apps for macOS without relying on Electron.
[1] https://github.com/necolas/react-native-web
[2] https://github.com/migueloller/HelloWorldApp
[3] https://github.com/react-community/react-navigation
[4] https://microsoft.github.io/reactxp/docs/components/navigato...
[5] https://github.com/lelandrichardson/react-primitives
I'm not sure I want to switch to ReactXP. I really like being able to use the React Native Animated API on the web, and I can also use wrapper libraries such as react-native-animatable.
I don't understand what you're trying to argue about. If you don't like it, don't use it.
As far as I understand, you don't need to do this in react-native. Only when you want to use some special features. Or am I missing something?
But as we move further, we'll be looking into making the versions for both platform feel truly native, and that will require some changes to navigation components and the overall navigation paradigm (tabs vs. drawer, screens vs. cards etc.).
The platform differences are as much about design as about code, and I don't see how you can escape that work with any cross-platform framework. But React Native makes it very easy to implement in a way that lets us share all but a few components.
It'd mean this framework is supposed to be a higher level React Native implementation: that you can use everywhere you want to use React, not just mobile.
Yes, it's not possible. You can't just use your React code as React Native. There are many small API differences.
They are saying that from what they know, if you use React Native, you shouldn't have to recode your UI layer for different platforms.
Which is true, but the point parent misses, is that it might not be necessary if you just want a cross platform app, but it is needed if you also want it to behave more like each platform users are used to.
But XP is EOL, so "XP" is never going to be used in anything now, thinking about it.
I can wish...
- Xamarin with .NET. Mobile apps only.
- ReactXP. Which also supports regular web-applications
It will be interesting to see if these two end up competing, or if one will be ditched in favour of the other.
Right now we're considering using .NET and ReoGrid, since Qt is too expensive and we only target Windows anyways.
Seems interesting. Hope they add linux support.
It came out of the Skype team. But it doesn't look like they're currently using it in their universal Windows app, which is built directly on XAML.
Parent specifically mentions they want to get away from the performance issues of web apps [1] -- and you suggest they use Electron -- and even bring up Atom and Slack as examples, the worst CPU/slowness offenders of all time?
[1] "Currently we are running into some performance issues with large datasets and spreadsheets, and being able to offer a performant desktop app would be ideal"
https://bvaughn.github.io/react-virtualized/#/components/Lis...
I think you should consider moving away from JS, it will probably save you from future problems.
I'm not arguing for or against ReactXP. Although if others start pushing the default to using ReactXP over React/React Native, that will be a disappointing repeat of history. My comment was addressing your statement:
> It has always felt off that React and React Native are so similar, yet you can't use the same code for web and apps.
There is no support of ReactXP for Window 7/8 so there is again Electron+Web as only viable option when using ReactXP.
They didn't mention web apps at all.
- React Native is faster than apps using a webview because it uses native UI components for their OS targets (e.g. Android and iOS). They also look more native.
- React Native runs the JS code in a separate thread from the native UI components rendering. Webview apps will use the same thread for their app code and the DOM rendering.
> With React and React Native, your web app can share most its logic with your iOS and Android apps, but the view layer needs to be implemented separately for each platform.
This is referring to web vs apps, in other words React vs React Native. That's the context of my reply. They are not talking about the (optional) differences within a React Native app to fit different platforms.
Qt doesn't support even half of the OS APIs that Xamarin does.
As for JavaScript based solutions, I don't intend to ever use it outside the browser.
As for ReactNative, give it two or three years and maybe then I will bother learning it.
As an old dog I have already seen too many carriages pass by, very few of them come back.