41–50 of 54 posts
From the code samples in README: var payload: () What does that mean? What type has payload? I throwed it inside Xcode, it does compile but i still don't understand it.
It's Void. In that example there is no need for the action to have a payload.
Earlier quoted context omitted.
What problems do you think the React + JS ecosystem could solve in the iOS world that haven't already largely been solved by standard iOS development approaches? I'm legitimately asking here - I been developing for iOS for years (and more recently with React from time to time for the web), and I've never once felt that standard iOS conventions/patterns were lacking compared to the React/JS ecosystem, but I would like…
Biggest problem is the lack of a proper way to update data thru the app. More often than not, we end with a big mess of singleton, notification, badly implemented kvo... and if you're not lucky, you'll have to fight to get an authoritative source for the data, or the latest one. When I see what's possible with solution like Om, I'm very envious (not that it's a silver bullet, but it's a major step forward in my point…
Looking cool, I think iOS development in general could learn a lot from React + JS ecosystem. :+1:
What problems do you think the React + JS ecosystem could solve in the iOS world that haven't already largely been solved by standard iOS development approaches? I'm legitimately asking here - I been developing for iOS for years (and more recently with React from time to time for the web), and I've never once felt that standard iOS conventions/patterns were lacking compared to the React/JS ecosystem, but I would like…
1) Deterministic View Renders 2) Deterministic State Reproduction
I think the following article gives a good overview of why this is a good idea:
https://medium.com/javascript-scene/10-tips-for-better-redux...
Quoting from the article:
"When your view render is isolated from network I/O and state updates, you can achieve a deterministic view render, meaning: given the same state, the view will always render the same output. It eliminates the possibility of problems such as race conditions from asynchronous stuff randomly wiping out bits of your view, or mutilating bits of your state as your view is in the process of rendering."
ComponentKit is another example of a native library inspired by react (also developed by FB):
Earlier quoted context omitted.
I've been working on an app that's more or less using ReSwift (I've hacked on it a bit). Can you elaborate on what you ran into that was complex/horrible?
I couldn't fix a lot of UI problems because when trying to trace what was happening through this system of actions and states I could only find when these bugs occurred when stepping between lines of machine code. I can't offer a fair point of view because I don't think the project I was working on made proper use of ReSwift. It was very difficult to follow the flow of data and understand why certain things wouldn't…
The last big project I worked on in Swift used an MVVM-style design. But I encapsulated the application state in a Swift enum.
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.
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).
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.
E.g., in the view controller:
let nextState = viewModel.nextStateForSomeButtonPressed()
AppState.transitionViewToState(self, nextState)
return MyAppState.BasicAlert("Title", "Message")
I have since found that this is one of the most pleasurable projects to maintain and update.
Edit:
This also allowed some nice functions to be written, like:
func initialApplicationState() -> [AppState]
Earlier quoted context omitted.
Biggest problem is the lack of a proper way to update data thru the app. More often than not, we end with a big mess of singleton, notification, badly implemented kvo... and if you're not lucky, you'll have to fight to get an authoritative source for the data, or the latest one. When I see what's possible with solution like Om, I'm very envious (not that it's a silver bullet, but it's a major step forward in my point…
You should try Realm. We radically simplified the architecture of our app by using Realm as the authoritative source of data (equivalent to a redux store) and then having all the views reacting to changes in the model. This also allowed us to have all writes happening background threads.
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'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.
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.
How would I achieve this behavior using a framework like this? How big/complex can this "single serializable data structure" get?
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. 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 developme…
I recently worked on an app that adopted a similar framework (ReSwift) and I hated it for the same reasons you are skeptical. It was needlessly complex, horrible to try and debug, and was incompatible with the "status-quo" of standard app development practices. At the end of the day it was just a bad replacement for Core Data / Realm / whatever. I wish I could tell you more but like yourself I really had absolutely n…