Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why reduce is static? #5

Open
mehdok opened this issue Sep 13, 2020 · 2 comments
Open

why reduce is static? #5

mehdok opened this issue Sep 13, 2020 · 2 comments

Comments

@mehdok
Copy link

mehdok commented Sep 13, 2020

Hi Vadim

First I have to thank you for your great article.

I'm wondering is there any specific reason that you used static function for reduce or feedbacks (whenLoading, userInput)?

@lordzsolt
Copy link

While I'm not the author of the article, I can at least partly answer your questions 🙂

They are static, because you should never need to access self inside them.


In case of reduce, it's also in the article:

Some of the states have associated values in order to draw them on the UI or to pass to the next state. Similarly, events carry data, which is the only source of information when we produce a new state inside a reduce() function.

In essence, the associated values of State and Event must be enough for you to determine the next state.


In case of feedbacks, either the State should be enough, or dependencies should be passed in as parameters.

However, the author conveniently hardcoded MoviesAPI inside the feedbacks and basically threw any notion of testability straight out the window...
Instead, that dependency must be injected.

The only question is, should it come with the State or should it be a parameter to the feedback function (ex: static func whenLoading(moviesApi: MoviesApi) -> Feedback<State, Event>).
I'm leaning more towards the 2nd approach of passing it as a parameter to the function.

@JonnyBeeGod
Copy link

While I'm not the author of the article, I can at least partly answer your questions 🙂

They are static, because you should never need to access self inside them.

In case of reduce, it's also in the article:

Some of the states have associated values in order to draw them on the UI or to pass to the next state. Similarly, events carry data, which is the only source of information when we produce a new state inside a reduce() function.

In essence, the associated values of State and Event must be enough for you to determine the next state.

In case of feedbacks, either the State should be enough, or dependencies should be passed in as parameters.

However, the author conveniently hardcoded MoviesAPI inside the feedbacks and basically threw any notion of testability straight out the window...
Instead, that dependency must be injected.

The only question is, should it come with the State or should it be a parameter to the feedback function (ex: static func whenLoading(moviesApi: MoviesApi) -> Feedback<State, Event>).
I'm leaning more towards the 2nd approach of passing it as a parameter to the function.

Makes sense. I am wondering whether you have figured out a way of making conditional presentation of modal views work with this approach. Since this would require to somehow set a Binding in the View based on the state of the viewModel and this does not work in the body func. Subscribing to state in init also does not work since this is an escaping func. Just wondering

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants