I have been trying hard to make my tech stacks as simple as possible. The less amount of tools being used, the less amount of things to debug, less time to compile, less tools to learn how to use.
RxSwift is one of those tools that is very large in size while I am using a fraction of it. It's also a tool that is difficult to learn. If it was a tool that I used the whole code base or I was able to download only a fraction of the Rx tool, I may consider keeping it. But at this time, it's like buying a house but only living in the bathroom all day. Might as well move into a smaller house.
Requirements
Thinking to how I use RxSwift, here are requirements I need for a replacement.
Testable. Should be very easy to write dependable unit, integration, and UI tests for. Able to test on simulator (Grand Central Dispatch calls need to be wrapped).
Able to cancel operation. Think about DisposeBag. When the UI is gone, be able to cancel the operation of observing. Cancel the HTTP request, cancel the DB query. Being able to cancel automatically like with DisposeBag would be great while making it optional otherwise.
Easy to switch threads. This is able to be tested with automated tests.
Allow throwing to happen somehow? Maybe I can't and I have to use Result<> in the callback?
Something I can use in my apps and in libraries. Simple, repeatable logic.
No dependencies. Just a wrapper around DispatchQueue while also exposing DispatchQueue? I say wrapper because I need to make DispatchQueue testable with automated tests.
No memory leaks.
Tasks
[ ] Remove need for Teller to use RxSwift. Use this logic in there. iOSBlanky cannot convert until Teller does because Teller has RxSwift tightly coupled right now.
[ ] Change HTTP requests to no longer using Single.
[ ] Change Core Data querying. Automatically observe for changes. The source code for RxCoreData is simple. Great starting point.
[ ] File changes. Get notified by file contents.
[ ] UserDefaults. Get notified when value changes.
[ ] Remove Rx dependencies!
Proposal
Create something that I use in the ViewModel. Something like backgroundTask.background { queueUtil → … } I have this code when the function first starts so that everything inside of it runs on a background queue.
This backgroundTask function returns a struct or new class back. Something that is destroyed when it’s done being used. Not a singleton, not a class that handles 1+ tasks running at once. 1 instance per task.
The returned class/struct is able to call assertMain() on it or similar function to check what function we are on. The struct/class keeps track internally via properties what queue is currently being executed. Check with properties because then a simulator can check these properties instead of running real dispatch queue code to check what queue we are on.
Make sure I can mock this backgroundTask class. Then in my tests, I can say “assert this is the order of operations: [background, background, UI] for each call to the class”. My tests I just need to confirm that the task started off on the background and ended in the UI. Maybe there is a way in my callback parameter I can check what queue is currently running.
I have been trying hard to make my tech stacks as simple as possible. The less amount of tools being used, the less amount of things to debug, less time to compile, less tools to learn how to use.
RxSwift is one of those tools that is very large in size while I am using a fraction of it. It's also a tool that is difficult to learn. If it was a tool that I used the whole code base or I was able to download only a fraction of the Rx tool, I may consider keeping it. But at this time, it's like buying a house but only living in the bathroom all day. Might as well move into a smaller house.
Requirements
Thinking to how I use RxSwift, here are requirements I need for a replacement.
DisposeBag. When the UI is gone, be able to cancel the operation of observing. Cancel the HTTP request, cancel the DB query. Being able to cancel automatically like with DisposeBag would be great while making it optional otherwise.Result<>in the callback?Tasks
Single.Proposal
Create something that I use in the
ViewModel. Something likebackgroundTask.background { queueUtil → … }I have this code when the function first starts so that everything inside of it runs on a background queue.This backgroundTask function returns a struct or new class back. Something that is destroyed when it’s done being used. Not a singleton, not a class that handles 1+ tasks running at once. 1 instance per task.
The returned class/struct is able to call
assertMain()on it or similar function to check what function we are on. The struct/class keeps track internally via properties what queue is currently being executed. Check with properties because then a simulator can check these properties instead of running real dispatch queue code to check what queue we are on.Make sure I can mock this backgroundTask class. Then in my tests, I can say “assert this is the order of operations: [background, background, UI] for each call to the class”. My tests I just need to confirm that the task started off on the background and ended in the UI. Maybe there is a way in my callback parameter I can check what queue is currently running.