This components doesn't need any state management library!

[JiLiZART]

Looking at #43

I have fear that this PR will be merged.
I think this component should be as "dump" as possible.
And guy who will use these components should decide what state management to use. Redux, Mobx, mobx-state-tree or other flux like library. And wrap this into HoC

[vincentaudebert]

Hi @JiLiZART I think it doesn't matter what state management we use inside this component.
It will be wrapped in the package and completely transparent for the final developer. You will still be free to use any state management library you want.

[ryami333]

@JiLiZART rest assured that we will not impose any kind of restrictions about which state management library this component will be compatible with, and whichever library we use, we promise that it will not impact the user at all. Like Vincent says - it will remain completely transparent in user-land.

Unfortunately, we are seeing many issues cropping up at the moment which are all related to the way that we are currently trying to pass state back and forth between our various components, and the only way to resolve this in a clean and maintainable way is to use some kind of contextual state management library. We could roll our own, but we would rather lean on well-tested and well documented libraries, for the sake of performance and reliability. Watch this space!

[ryami333]

@JiLiZART v2.0.0 dropped today, and you'll be pleased to know that it remains 'dumb' in the sense that you do not need to integrate it with your existing state infrastructure, even though it uses mobx + mobx-react behind the scenes. Incidentally, we are actually going to try and move to something a bit lighter pretty quickly though - we're not too pleased with how much bloat mobx adds to the library!

[JiLiZART]

Okay, +57kb to bundle, nice 👍

[ryami333]

@JiLiZART - we've shaved that back off again with our latest release, where we replaced mobx with unstated 😄 Enjoy!