Skip to content
This repository has been archived by the owner on Feb 19, 2022. It is now read-only.

Calculated states giving me the blues #102

Open
bingomanatee opened this issue Mar 13, 2018 · 1 comment
Open

Calculated states giving me the blues #102

bingomanatee opened this issue Mar 13, 2018 · 1 comment

Comments

@bingomanatee
Copy link

I'm getting very unreliable results from calculated states. I'm not too blue because they are not core to freactal - I can always expose them as external library operations around the state data -- but I think their caching or other operations seem to be caching the computation in an invalid value.

I can detail the scenario I am running into.

I am using Auth0 and integrating it with Freactal. One thing that the auth gives you is an "expiresAt" field that I am caching with local storage.

I wanted a semantic "isLoggedIn" computed value that is as follows:

  • if expiresAt is not truthy (absent or null/zero) , return false. (am not logged in)
  • if expiresAt is in the past (< new Date().getTime()) return false.
  • else return true.

The paradox I am getting it is this. I am persisting the computational function outside the configuration and when I pass state to it, the external isLoggedIn is returning true. However I am doing this in a block in which the computed value is false:

I have an effect that this paradox is running in:

   logoutIfNotLoggedIn: (events) => (state) => {
           if (!state.isLoggedIn) {
             const loggedIn = bottle.container.isLoggedIn(state); // 'bottle.container.isLoggedIn' is code I have copied to my computed definitions
             eval('debugger');
            events.logout();
          }
          return state;
        }
      ,

local loggedIn is true -- even though you can't even reach this code unless the computed property is false!

so long story short - I would be very careful around computed values and probably advise not using them until they are revisited.

@agurtovoy
Copy link
Contributor

agurtovoy commented Mar 18, 2018

FWIW, there is another issue with computed props where using a state prop in a computed prop calculation effectively makes that state prop global/non-overridable (you'll get an error if there is another identically named prop anywhere in the component subtree). Didn't have time to report this properly yet.

Edit: JFYI, reproduced and fixed here.

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

No branches or pull requests

2 participants