blacklist functionality broken?

[zciendor]

First, let's look at what is working as expected:

createPersistedState({
  blacklist: (mutation) => {
    return true
  }
})

This will never persist any state. However, this is a bit pointless as the same result could be achieved by not using the createPersistedState plugin at all.

Now let's look at the case when blacklisting certain mutations, by providing a list of mutations:

createPersistedState({
  blacklist: ["ignoredMutation"],
})

Well, it's true that the state is not persisted when ignoredMutation is fired. However, the whole state will be persisted the next time a non-blacklisted mutation is triggered - which includes all the previous mutations, even the blacklisted ones. Basically you're only delaying persistence that way but not blacklisting it.

So the question is: Is this implemented as designed? If yes, where's the point in that?
The only use I can imagine is that it allows you to blacklist certain mutations for performance reasons (e.g. in case they are triggered that often that you don't want to write to the persistence file every time). But I doubt that this is what users would expect based on the limited documentation.

[MaverickMartyn]

I would like an update to this as well.
I am currently having issues where one of my state items is updated very frequently, and I would like to not persist it to disk.
I often have permission issues, since the file is already being modified, and I think this could fix it.

[MaverickMartyn]

@zciendor Update:
You can take a look at my fork, and use that until this is fixed (I created a pull request containing my fix).
In my fork, you can use the "ignorePaths" option to avoid persisting specific parts of the state object.
It just takes an array of strings. An example could be ["module.statevalue.anothervalue"].
You can combine it with the existing blacklist functionality, to also block mutations.
If you do not block the mutations, the rest of the state will still be saved, just not any blocked values.
This could be an issue with state items that are often mutated.
So I recommend using both. :)

[akodkod]

#44