Render alternatives and similar libraries
Based on the "Reactive Programming" category.
Alternatively, view Render alternatives based on common mentions on social networks and blogs.
-
OpenCombine
Open source implementation of Apple's Combine framework for processing values over time. -
Tokamak
DISCONTINUED. SwiftUI-compatible framework for building browser apps with WebAssembly and native apps for other platforms [Moved to: https://github.com/TokamakUI/Tokamak] -
Interstellar
DISCONTINUED. Simple and lightweight Functional Reactive Coding in Swift for the rest of us. :large_orange_diamond: -
Verge
๐ฃ A robust Swift state-management framework designed for complex applications, featuring an integrated ORM for efficient data handling. -
VueFlux
:recycle: Unidirectional State Management Architecture for Swift - Inspired by Vuex and Flux -
RxReduce
DISCONTINUED. Lightweight framework that ease the implementation of a state container pattern in a Reactive Programming compliant way. -
LightweightObservable
๐ฌ A lightweight implementation of an observable sequence that you can subscribe to. -
ReactiveArray
An array class implemented in Swift that can be observed using ReactiveCocoa's Signals -
STDevRxExt
STDevRxExt contains some extension functions for RxSwift and RxCocoa which makes our live easy. -
RxAlamoRecord
RxAlamoRecord combines the power of the AlamoRecord and RxSwift libraries to create a networking layer that makes interacting with API's easier than ever reactively.
InfluxDB - Purpose built for real-time analytics at any scale.
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of Render or a related project?
Popular Comparisons
README
Render [](#) [](#)
CoreRender is a SwiftUI inspired API for UIKit (that is compatible with iOS 10+ and ObjC).
Introduction
- Declarative: CoreRender uses a declarative API to define UI components. You simply describe the layout for your UI based on a set of inputs and the framework takes care of the rest (diff and reconciliation from virtual view hierarchy to the actual one under the hood).
- Flexbox layout: CoreRender includes the robust and battle-tested Facebook's Yoga as default layout engine.
- Fine-grained recycling: Any component such as a text or image can be recycled and reused anywhere in the UI.
TL;DR
Let's build the classic Counter-Example.
The DSL to define the vdom representation is similiar to SwiftUI.
func makeCounterBodyFragment(context: Context, coordinator: CounterCoordinator) -> OpaqueNodeBuilder {
Component<CounterCoordinator>(context: context) { context, coordinator in
VStackNode {
LabelNode(text: "\(coordinator.count)")
.textColor(.darkText)
.background(.secondarySystemBackground)
.width(Const.size + 8 * CGFloat(coordinator.count))
.height(Const.size)
.margin(Const.margin)
.cornerRadius(Const.cornerRadius)
HStackNode {
ButtonNode()
.text("TAP HERE TO INCREASE COUNT")
.setTarget(coordinator, action: #selector(CounterCoordinator.increase), for: .touchUpInside)
.background(.systemTeal)
.padding(Const.margin * 2)
.cornerRadius(Const.cornerRadius)
}
}
.alignItems(.center)
.matchHostingViewWidth(withMargin: 0)
}
}
Label
and Button
are just specialized versions of the Node<V: UIView>
pure function.
That means you could wrap any UIView subclass in a vdom node. e.g.
Node(UIScrollView.self) {
Node(UILabel.self).withLayoutSpec { spec in
// This is where you can have all sort of custom view configuration.
}
Node(UISwitch.self)
}
The withLayoutSpec
modifier allows to specify a custom configuration closure for your view.
Coordinators
are the only non-transient objects in CoreRender. They yeld the view internal state and
they are able to manually access to the concrete view hierarchy (if one desires to do so).
By calling setNeedsReconcile
the vdom is being recomputed and reconciled against the concrete view hiearchy.
class CounterCoordinator: Coordinator{
var count: UInt = 0
func incrementCounter() {
self.count += 1 // Update the state.
setNeedsReconcile() // Trigger the reconciliation algorithm on the view hiearchy associated to this coordinator.
}
}
Finally, Components
are yet again transient value types that bind together a body fragment with a
given coordinator.
class CounterViewCoordinator: UIViewController {
var hostingView: HostingView!
let context = Context()
override func loadView() {
hostingView = HostingView(context: context, with: [.useSafeAreaInsets]) { context in
makeCounterBodyFragment(context: context, coordinator: coordinator)
}
self.view = hostingView
}
override func viewDidLayoutSubviews() {
hostingView.setNeedsLayout()
}
}
Components can be nested in the node hierarchy.
func makeFragment(context: Context) {
Component<FooCoordinator>(context: context) { context, coordinator in
VStackNode {
LabelNode(text: "Foo")
Component<BarCoordinator>(context: context) { context, coordinator in
HStackNode {
LabelNode(text: "Bar")
LabelNode(text: "Baz")
}
}
}
}
}
Use it with SwiftUI
Render nodes can be nested inside SwiftUI bodies by using CoreRenderBridgeView
:
struct ContentView: View {
var body: some View {
VStack {
Text("Hello From SwiftUI")
CoreRenderBridgeView { context in
VStackNode {
LabelNode(text: "Hello")
LabelNode(text: "From")
LabelNode(text: "CoreRender")
}
.alignItems(.center)
.background(UIColor.systemGroupedBackground)
.matchHostingViewWidth(withMargin: 0)
}
Text("Back to SwiftUI")
}
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView()
}
}
Credits:
Layout engine:
*Note that all licence references and agreements mentioned in the Render README section above
are relevant to that project's source code only.