This feels a bit like a solution without a problem, or maybe more like a giant sledgehammer-sized solution to 10 or 15 smaller ant-size problems.<p>I guess I'm just not sure what advantage I'd get by taking a (frankly) mind-bending approach to building an iOS app instead of following normal iOS conventions. And just to be clear I've done React development on the web, and I've thoroughly enjoyed it. Modern web development is mind-bending enough that React (and other approaches) felt like they brought some sanity to the table, but this doesn't feel like that. It feels overly complicated for iOS development, which feels like a largely solve problem.<p>What am I missing? I'm really not trying to be critical, I'm really trying to understand why you'd recommend I use this approach over standard iOS patterns. In the 8 years I've been developing for iOS I've never felt like I needed anything I've seen in here (or in any of the getting started tutorials I read through), but I'd like to try to see what I'm missing here.
The one issue I see with bringing Flux/Redux to iOS is that iOS shipped with unidirectional data flow from day 1 with KVO: view => IBAction on controller => model method (incl. any API or CoreData work) => controller is notified of changes via KVO => rerenders view via a pure function. I don't think it was struggling for a new, clean solution here in the same way the web was.<p>That said, for people used to the React patterns, this could be a somewhat easy way to make the transition over to iOS programming! So that's cool :D
I'm one of the author of the framework :)
please let me know if you like our approach to apps development we internally use it for creating our own apps at Bending Spoons (<a href="http://bendingspoons.com" rel="nofollow">http://bendingspoons.com</a>)
> logic: the app state is entirely described by a single serializable data structure<p>I'm curious how frameworks like this handle dealing with large amounts of data? Let's say my data source has 25,000 rows that I need to search and filter through at any given time.<p>Using standard iOS paradigms I might store the data in a SQLite database using Core Data, use an NSFetchedResultsController to search the data, and display it using a UITableView. Any changes to the underlying data (insertions/deletions/updates) are automatically tracked and dealt with so the UITableView is kept up to date as the data changes. Behind the scenes there are lots of optimizations occurring in Core Data and the NSFetchedResultsController so only the data for visible rows are loaded into memory at any given time.<p>How would I achieve this behavior using a framework like this? How big/complex can this "single serializable data structure" get?
If you're willing to take a leap like this for an iOS project, why not just use React Native? At least with that you get a much more portable codebase, not to mention the benefits that come with its growing ecosystem.
I found the following repo example of something React inspired too, but using f#. There's also a youtube video with a great explanation of the concepts on the repo. This guy also created an IDE for F# for the iOS. It is a great resource too...
github: <a href="https://github.com/praeclarum/FunctionalMeetup" rel="nofollow">https://github.com/praeclarum/FunctionalMeetup</a>
youtube video: <a href="https://www.youtube.com/watch?v=_Qk7ZcyYZwA" rel="nofollow">https://www.youtube.com/watch?v=_Qk7ZcyYZwA</a>
ios app: <a href="https://itunes.apple.com/us/app/continuous-.net-c-and-f-ide/id1095213378?mt=8" rel="nofollow">https://itunes.apple.com/us/app/continuous-.net-c-and-f-ide/...</a>
I have kind of gone half-way between a full-blown React model and MVC for iOS development.<p>The last big project I worked on in Swift used an MVVM-style design. But I encapsulated the application state in a Swift enum.<p>The enum adhered to a protocol `AppState` which defined a method to turn an `AppState` into a view controller, as well as a static function to transition a view controller to a new `AppState`. Swift's strong type system ensured that it was very easy to guarantee that every view controller / view model had access to well-defined data types and that the flow of information only happened in one direction.<p>This meant that the entire transition logic for the application sat in one relatively small file that handled how each state could be displayed (and whether special cases were needed if coming from a particular state).<p>So for example, to present an alert in the application a view controller would ask its view model for the next AppState, and then ask to transition to that state.<p>E.g., in the view controller:<p><pre><code> let nextState = viewModel.nextStateForSomeButtonPressed()
AppState.transitionViewToState(self, nextState)
</code></pre>
And the view model's next state logic might be:<p><pre><code> return MyAppState.BasicAlert("Title", "Message")
</code></pre>
The enum .BasicAlert has all the logic needed to transform into a view controller (in this case a `UIAlertController`), and the transitionViewToState has all the logic needed to present that controller.<p>I have since found that this is one of the most pleasurable projects to maintain and update.<p>Edit:<p>This also allowed some nice functions to be written, like:<p><pre><code> func initialApplicationState() -> [AppState]
</code></pre>
Which the AppDelegate uses on startup to display the correct array of view controllers (in this case, the app displays a tutorial sequence on first-run, but that logic is completely decoupled from the AppDelegate).
How do you deal with the main thread and thread safety? Being able to 'modify' views off the main thread would be the largest advantage of something like this, kind of like async display kit
From the code samples in README:<p>var payload: ()<p>What does that mean? What type has payload? I throwed it inside Xcode, it does compile but i still don't understand it.