> 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?
Totally agree with them on that. I love observable-style code vs the full Flux. Especially when I want a small, self-contained component. Redux in particular sort of asks you to not make your components self-contained, since you've got a single global state store. There are apps where it makes sense, but anything not full-blown-SPA-to-the-max can be really cumbersome with the flux pattern.
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.
I've very successfully used the observable pattern since backbone/knockout days with Spine, on web, node, and Titanium. It is easy to create reusable components and follow the data flow, regardless of data source or view implementation.
These days I use virtual DOM for performance but the architecture hasn't changed in years. The observable pattern with viewmodels is very efficient.
That's also how I perceive flux/redux. It's promise is to make it easier to"reason about your application". But it's basically a glorified event model, which does have some nice properties, but you end up with one function bring scattered throughout your entire application as side effects (which you need anyway, be it as sagas, thunks or whatever). Now as your application grows out becomes really hard to follow the flow and if you dispatch an action, it's not clear what will happen because of this. Am I just not getting it right?
Despite explaining that XP stands for "cross platform", I still think that this is mis-named and many will assume it relates to one of Microsoft's biggest ever brand names with global recognition.
At first glance I decided not to read the article because I thought it irrelevant due to the XP.
I would really love if MS brought out some kind of .net core electron alternative. Xaml is nice enough to build UI with, .net core works across macOS and Linux, and the whole package wouldn't need an entire copy of chromium for each install
React-native is different from electron apps, though. I don't think they need chromium, just the Javascript portion of it.
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.
No... :D Why would anyone use it then, you could just as well wrap a regular webview. RN's gui elements are native, it taps into native animations, schedulers, openGL and so on. But driven by Javascript running in a separate thread. RN produces real mobile apps, RN-windows real UWP applications, RN-macos real mac apps, and so on.
You heard the opposite of reality. Here are the key facts:
- 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.
There is Xamarin.Forms, which is essentially cross platform XAML with a base set of widgets. It supports Android, iOS, UWP, and they are working on MacOS. No Linux yet.
I have same feelings for js in general, but I suggest you to try React Native. Just follow their official docs/tutorial. I was pleasantly surprised how straightforward it is. I believe you can as well use TypeScript.
You should bother with React Native. It game changer in the mobile world, not a trendy thing that will pass away. Senior iOS devs are going the RN route. Companies all over the places use it for their mobile clients. A little company named WIX recreated its entire mobile front with React Native.
I beg to differ. The xamarin stack on Android without forms is much preferable to whatever confused iteration of java+toolchain Google is currently offering.
I'm a bit skeptical this is needed at all. I would've much preferred if Microsoft contributed to the already popular React Native for Web [1].
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.
I've been developing a cross-platform app with React Native, and react-native-web has been working really well. It took almost no effort to get my React Native app working in a browser. I might be wrong, but it looks like ReactXP is just an alternative to react-native-web, with some additional abstractions and conventions for stores, etc.
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.
Am I the only one who thinks this is a big deal? This basically means you can finally share your React code across platforms. 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.
Like Java? Or QT? React Native being different for different platforms was kind of the point. "Learn once, write anywhere." This meant they could focus on wrapping the features of each unique platform without having to worry about how that affects supporting all of them simultaneously. Otherwise you get the lowest-common-denominator effect of supporting only the available APIs common between all platforms. And all of the painful effort of making sure everything works consistently and predictably across all platforms.
It fits some kind of apps. I've built one React Native app where the "lowest-common-denominator" was more than good enough (no special code for different platforms) and would have worked just as well as a web app but wasn't possible due to the nature of React/React Native. If I would have used ReactXP I could have published it on the web as well and used just one React code base so this is good news for me.
I don't understand what you're trying to argue about. If you don't like it, don't use it.
> I don't understand what you're trying to argue about. If you don't like it, don't use it.
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.
>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.
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?
It depends. In our current app, all we needed to implement separately was the margin for the status bar, literally two lines of code.
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.
With RN, if you want your app to look like a real native app, you have to implement things separately for iOS and Android. Eg the default navigation component animates differently than native iOS, and there is an extra component that uses the native UINavigationBar, but with that you need to manage the iOS navigation stack separately.
The description is obtuse, but I think they mean separately between web and mobile, not iOS and Android.
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.
Parent is not saying (or asking whether) you can "use your React code as React Native".
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.
What are different platforms referring to here? The quoted sentence sounds like it means web vs apps but you (and the parent?) make it seem like we're talking about Android vs iOS.
Parent was saying "you don't need to do this in react-native" regarding the following sentence:
> 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.
As a previous c# programmer, the language is pretty powerful now, it has things now that can make c# look poor in some aspects, but, you get there only through a setup. If you have tried JS with node being installed, npm, webpack, babel and all this stuff, the experience will be poor. Though with these things in check, there's nothing that will pull me back.
I really want React for desktop apps. 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.
Right now we're considering using .NET and ReoGrid, since Qt is too expensive and we only target Windows anyways.
You can use Electron and do that. Not a ton of love for it around here because omg a web page as a desktop app the horror but I've had good experiences with it. (And if you e ever used Slack or Atom, you've used Electron)
>You can use Electron and do that. Not a ton of love for it around here because omg a web page as a desktop app the horror but I've had good experiences with it.
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"
You can use Electron to handle performance-sensitive large datasets and spreadsheets for a desktop app. But I think there is an even better solution for this: you could program it in DOS 5.0 batch and ship it with a Windows 3.1 VM to really juice out that last bit of performance and efficiency.
.NET and WPF is a great choice for desktop applications. I have been creating desktop applications with WPF for the better part of a year, I find it very nice.
If you have a performance problem and you only target one OS, using React seems more like a band-aid than a real solution. I assume your app is currently written in javascript, because I don't see any other reason to use React for performance.
I think you should consider moving away from JS, it will probably save you from future problems.
It was originally supposed to be (and built as) a web app, but it's only being used inside a corporate network (yay requirements). So that defeats the original purpose. Might as well make a desktop app.
>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. We have taken this a step further and developed a thin cross-platform layer we call ReactXP. If you write your app to this abstraction, you can share your view definitions, styles and animations across multiple target platforms.
That's interesting. But I wonder if many product developers will be ok with a common view layer -- Android and iOS's UX and design language are different (Icon sizes, tab bar, back button... all that).
> ReactXP currently supports the following platforms: web (React JS), iOS (React Native), Android (React Native) and Windows UWP (React Native). Windows UWP is still a work in progress, and some components and APIs are not yet complete.
ah, yeah that hasn't changed. I've been using Skype preview on Win10 and it's very nice. It's very much a native desktop app - certainly it's the successor to the old Delphi client.
I can't find any instructions on how to try any of the samples: supported host platforms, prerequisites, downloading the toolkit, building the samples, etc.
Don't forget that UWP targets only Windows 10 and moreover it unifies development cross Desktop and Mobile. So we can read React UWP as small support of easy deployment to Windows 10.
There is no support of ReactXP for Window 7/8 so there is again Electron+Web as only viable option when using ReactXP.
With RN's and Expo's out of the box support for Android/iOS, I find the missing piece is native support for Responsive Grid layout. Till then, I've derived one based on the new support in RN v0.42 for relative dimensions. I've taken the liberty of correcting the mental model for Grid to eliminate the decoherence that results from using both an absolute column count together with relative sizing (!) by letting the developer specify grid column width as a percentage of screen size and allowing the specifying of the width of a given column in the layout as a multiple of that percentage. This way the developer doesn't have to divide the screen size in pixels (assuming they know that for the screen they're testing on, which is not always the case) by some arbitrary number of grid columns in order to get the width they desire per grid column (indirect route.) They can instead use visual intuition about relative sizes to define the column width directly as a percentage of screen width. I also found RTL support (for Hebrew/Arabic apps) generally lacking in RN, so I added RTL layout support to it.
It's not just different platforms but different screen sizes (and RTL layouts) that's the biggest challenge I found in developing React Native apps. To solves those challenges, I'd like to share something I've been working on: a responsive grid for RN with RTL layout support. It has reduced the time it takes to build relative size and responsive layouts by a factor of 10, easily. It's based on previous similar work but with some radical changes and a few functional and usability enhancements. Looking for testers!
> 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