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

Behavior of skipRepeats unintuitive #352

Open
AlexanderBollbach opened this issue Jun 2, 2018 · 6 comments
Open

Behavior of skipRepeats unintuitive #352

AlexanderBollbach opened this issue Jun 2, 2018 · 6 comments

Comments

@AlexanderBollbach
Copy link

If i explicitly define a skipRepeats function on my subscription selection I feel that it should take precedence over my type's == implementation. More than a few times I've been burned by not realizing the Subscription is forgoing skipRepeats because its selection is Equatable.

@DivineDominion
Copy link
Contributor

That doesn't sound like what I'd expect to happen, but I'm not using skipRepeats at all myself. So could you illustrate the issue with minimal breaking code? What do you write, what do you expect to happen, what happens instead?

@AlexanderBollbach
Copy link
Author

AlexanderBollbach commented Jun 3, 2018

say i subscribe to the store

  store.subscribe(self) {
            $0.select {
                $0
                }.skipRepeats({ (old, new) -> Bool in
                    return old.activeProject == new.activeProject
                })
        }

If my AppState is Equatable and I have == return true, than the skipRepeats closure is not called. If I make == return false than it will be called. I think that if I remove the Equatable conformance of AppState than it might also call the skipRepeats closure but I haven't tried that because too much would break.

It seems that the current behavior is that if the type is Equatable and if == returns true than skipRepeats closure is never called.

@DivineDominion
Copy link
Contributor

Aha, now I understand -- there's two skipRepeats, one invisible. Your best bet for now is to deactivate skipRepeats for equatable states upon store initialization.

This is related to #259 and not yet fixed.

@DivineDominion
Copy link
Contributor

A solution as per #259 could be to return an AutoSkipRepeats<S> type from select that ditches its own equatability check once the user invokes skipRepeats.

@marktrobinson
Copy link

Any solutions to this?

@dani-mp
Copy link
Contributor

dani-mp commented Aug 7, 2018

I've been thinking about this and maybe I'm missing something, but the second skipRepeats will always return true if the app's state doesn't change, right? Unless you're introducing a side effect in the selector function, which should be pure.

Do you have a case where the app's state doesn't change and a selection of parts of the substate could yield a different result?

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

No branches or pull requests

4 participants