I use react-native solely for the UI which I update, redux-style, with a state-tree. The state and all it's transition and event-handling is done in Kotlin/Java.
I've written a small helper that generates kotlin-Interfaces from the react/jsx-files and automatically connects everything.
This way I have react's HotReload and the other benefits for UI-design and a proper typed language and IDE for networking and everything else. Including compile-time checking of events and properties of the UI.
Plus: Kotlin can compile to JavaScript, so if I ever want to port the whole thing to iOS, i just have to switch out a few APIs.
Just to mention, if you enjoy Kotlin - you might want to try Anvil+Bansa. It is like React+Redux, but for Kotlin (or Java). Resulting APKs are much smaller than React Native and don't rely on jni code.
I've thought about Anvil, but I like React and I can reuse stuff from my web-development. Like tachyons styling [0].
Regarding bansa: Sounds nice, but I've never seen the benefit of using a library for state and state-reduction. You can implement and customise for yourself in less than 50 lines. (I don't use the redux library on the web either)
The only thing I would like is being able to reuse data-structures of react-native, so they won't get serialized all the time.
Sounds like a great use case of React Native where RN is specifically used for what it is designed for: the UI layer. I've done apps with both approaches (all RN or UI-only RN), and I'd love to read or see more about your approach.
Maybe I'll write something longer about it, but i haven't figured everything out myself yet.
I have a Controller that takes UIEvents and NetworkEvents from a BlockingQueue (CSP). The state reduces everything. Kotlin's "when" constructs are extremely convenient here, but want to make sure I'm not going to far into the functional direction, if you get what I mean.
The state is completely serialisable (in fact gets serialised to and from JSON in onPause/onResume).
I'm doing networking declaratively as well, a serialisable request-description is put into the state and it's the "NetworkManager"'s job to figure out which requests to start or stop.
Kotlin's delegated property are also awesome, because I can mix and match functions and variables.
/* show loading animation */
override val isLoading by stateFn {
it.runningRequests.any { it is LoginReq }
}
I agree. A lot of times I'm just perusing HN for a few minutes as a break; I'm not looking for heavy reading. Setting up the content like this gives me a quick little chuckle in-between paragraphs and I move to the next. Rather than oh god this is too long - next link.
The criticism on the tooling seems excessive for the benefits it provides. On one hand you don't spend the time equally on the terminal, the text editor, dev tools and the platform's IDE. You'll normally spend most of your time in the text editor and the emulator. You'll have to use the other tools here and there, but in exchange most of your code will be shared across platforms.
Regarding code organization, I found redux to be a well established tool with clear patterns.
> With each framework or platform we develop with we need to adapt to the conventions. From back end work using frameworks like Rails and Elixir to native mobile projects each has it’s own way to hang together a project.
Some have their own way to hang together a project. Much of the React ecosystem is not so opinionated. A lot of JavaScript out there exists in codebases in a variety of languages and frameworks—Rails, PHP, Node... you name it. Modern JavaScript build tools reflect the need for script sources and build targets to reside anywhere based on what the site JavaScript is being used in. I'd say this historical influence is showing in React Native.
However, I also think this makes sense for React Native. It's possible it's getting introduced into apps which already have conventions based on the platform the app is for and the team writing it. It might not make sense for React Native to come up with a new set of conventions when you're working with multiple platforms and existing codebases.
> But the real value is in sharing code, maintaining projects and on boarding new members to a project team. [...] We’ve spent a long time viewing projects on GitHub and picking and choosing what we feel is the best way a project should be structured.
Conventions—whether they're forced on you by the framework authors or developed by the community—are still part of learning a framework and working with it for the first time. I'd say what author came away with here is even more important than just having some convention—they landed with something they really think is best for their projects! The real cost here is that onboarding developers will also include time for them to get familiar with this project structure, but is that really so much to ask?
I wouldnt recommend react for any app which you want togo big. In the end, you need to rewrite it to native code anyway, because you want to use the latest feature, or because you have bugs because react native doesnt follow the platform guidelines (activities, activity stack, etc)
> When you develop a fully native app you do it pretty much in one place. On iOS you’re in Xcode, for Android you’re in Android Studio. With React Native you have a terminal (with a couple of panes), a text editor, perhaps Redux Remote DevTools plus your IDE for the platform you’re targeting.
It's not like those IDEs can't be configured to work with the raw tools.
The case for React is strong in this respect, because Facebook has many lines of React committed to important production code. Your problems are also their problems... unlike Angular, which Google isn't relying on in production code nearly as much.
I don't mind switching between different contexts, I frequent the terminal for git an other stuff anyway. I think it is fairly magic that one may finally develop the same code for both iOS and Android. Huge productivity win, especially using Clojurescript!
Many of the points made in the article boil down to React Native still being a relatively new framework, and the team and community behind it iterating very quickly.
Sure there will be growing pains starting out, but the benefits that are coming from this new direction are, in my opinion, worth all the effort. I've written several apps utilizing React Native now, and love the efficiency boost it gives me.
HN community, how would I make my core model + business logic cross-platform? I want to re-use the model and its behavior (like some data evaluators) in my Web app, on Android and iOS without rewriting it every time from scratch. I'm fine with creating native code for the UI. but I'd like to share at least some code. What would you recommend?
What I do is write the model and bussiness rules in Java, and I use J2ObjC[0] to export it for iOS. The configuration is not pain free, but once set up it has been extremelly reliable for me. I don't need to support web, but I hear GWT[1] works well for this. I don't see why JSweet[2] would not also work.
If you use react native on mobile and react on the web the core model and business logic can easily be shared since it is just pure js. And you can use any of the languages that transpiles to js: TypeScript, Clojurescript etc.
The performance is impacted, avoiding premature optimizations I haven't looked into that part yet though. Without any performance optimizations I'm experiencing performance better than HTML5 but not really on par with native. To me the value of sharing the logic and the crazy fast development speed is more valuable than a few milliseconds of delay. At least in this stage.
For me C++ is all I need for portable native code, no need to add extra layers that kind of work, that only increase code entropy and debugging efforts.
Directly available in iOS, Android, WP, Tizen, Ubuntu SDKs.
The only major problem is the way Google disregards their NDK stack, while Microsoft and NVidia engineers are able to do what Google PhDs are not.
I use react-native solely for the UI which I update, redux-style, with a state-tree. The state and all it's transition and event-handling is done in Kotlin/Java. I've written a small helper that generates kotlin-Interfaces from the react/jsx-files and automatically connects everything.
This way I have react's HotReload and the other benefits for UI-design and a proper typed language and IDE for networking and everything else. Including compile-time checking of events and properties of the UI.
Plus: Kotlin can compile to JavaScript, so if I ever want to port the whole thing to iOS, i just have to switch out a few APIs.