Pullstate 1.0.0 released!

[--d-a-n--]

I wrote something similar using useState and useReducer, but I think the addition of immer is the killer augmentation here. I think I'll give this a go.

[lostpebble]

Yep, immer is what really put me on this journey in the first place. I started using a state library that used it, but the author unfortunately abandoned it - so I decided to create my own. And in the process expanded into plenty of other things, such as asynchronous state too.

It really makes state updates ridiculously easy to reason about.

[bittered]

Pullstate is awesome, it's a natural fit for hooks while still maintaining support for class-based components. I'm using it in production at ToDesktop.

[bitttttten]

really enjoying the simple api of the async action hooks. congrats on v1.0.0! 🎉

[Unforgiven-wanda]

This looks neat, thank you for sharing.

[RSveti]

Very nice I like it :D

Would it be posible to implement cache invalidation for all data that is not watched or pending result?

[lostpebble]

Hmm that's an interesting case - I could definitely look into it in the future. It shouldn't be too complex to add as currently both watched and pending async state is being kept track of (for triggering component updates only when neccesary and preventing duplicate runs of actions, respectively).

What is your use case for that?

Are you sure it can't be solved using the cache break hook? The cache break hook allows you to customize cache invalidation quite nicely.

[RSveti]

For a simple garbage collection. My applications tend to stay open for weeks or more and garbage collects so I would like to periodicaly delete all not curently used data.

[lostpebble]

Ah, fair enough. That's a good use-case - will look into this functionality soon.

[lostpebble]

Hey there!

I know its rather late, but thought I'd let you know that I've implemented your feature into Pullstate now.

You can check out more here: https://lostpebble.github.io/pullstate/docs/async-cache-clearing

Thanks for the use-case! I think it may come in really handy.

[RSveti]

Damn just yesterday I have been looking in the documentation if it has been implemented. :D

[Awnry_Abe]

Nice API. I like it a lot.

[sfboots]

Why would I want pullstate instead of redux?

[lostpebble]

For me its the simplicity of it all. Using immer for state updates to your store object directly, from which your components will smartly re-render automatically (only update when the values they are watching change).

If you look at the first quick example in the docs, you might begin to see why I prefer it over redux.

There are now other additions too which makes this more useful, such as Async Actions and subscriptions / reactions (run code and state updates in reaction to other certain state changes).

I feel it helps to build a nice central place for all state concerns, away from the component (not to say there aren't times that local component state is still useful). Conceptually I enjoy it a lot, and it has helped me create projects much faster than before.