Rxswift: Best Practice

[lfaoro]

What do you guys think about writing a concise "Best Practices" for creating Observables and subscribing to them. So far we know there are multiple ways of doing the same thing, awesome, whomever can choose how they prefer to work but... we have a preferred way elegantly explained to the user.

Same principle as for example: Swift Style Guide

[danielt1263]

I think that when users feel the need for a style guide, it means the library/language in question is starting to loose focus. Note that there are already two Swift Style Guides on github (the one you cited and https://github.com/github/swift-style-guide) and this is _not_ a good thing IMHO.

That said, I think there should be more documentation on how to create Observables and subscribe to them. There are a lot of libraries out there that push data and need data pushed to them but don't use RxSwift, and we need to understand better how to make Rx wrappers around them.

[lfaoro]

:+1:

[kzaher]

Hi :)

I've tried to explain how to create observables here.

This entire GettingStarted.md was intended as a place to explain concepts to new users, and I've tried to take it one step at a time.

Do you feel that description was understandable, or were there some things that you find confusing :)

Basically, I gave it my best shot at explaining how things work :)

I think that every imperative API can be abused no matter how well it's designed.

For example what could be wrong with a simple map method on array? Well, you can introduce side effects in transformation closure :)

I wish Swift would had a pure keyword that marks lambda or function as pure function.

Or better yet, compiler enforcing purity by default and make us mark non pure functions/closures with mutating :)

So you could just do grep mutating :)

Anyway, unwinding the stack ....

I've found an Rx gem. These are original guidelines that Microsoft team wrote for Rx.

I wish I've read these a long time ago :) I've kind of gone reverse way, figuring what the designers had in mind from reading the Rx code itself :)

It is for C#, and it does have situations that don't apply to Swift case, but the good thing is that I think I've manage to separate Rx idea from particular implementations, although reading this document sooner would make my experience sooooo much easier :)

[kzaher]

If there are some areas of documentation that are particularly bad, we can open issues for them, otherwise closing this for now :)

[danielt1263]

There is also this book to help with best practices. It's for Rx.net, but it may still help: https://go.microsoft.com/fwlink/?LinkID=205219